How to build an app with AI

The single biggest factor in whether this goes well is what you choose to build. Good first projects share three properties: you understand the problem yourself, the app is for a small known audience, and being wrong is cheap.

That points you at internal tools, personal utilities, trackers, calculators, and prototypes. It points you away from anything that takes payments or holds strangers' personal data on day one. Not because it cannot build those, but because judging whether it built them correctly takes skills you should acquire on something lower stakes.

For this walkthrough the example is an equipment checkout tracker for a small video production team. It is a real shape of problem: a handful of people, some expensive gear, and a group chat where "who has the C70?" gets asked twice a week.

Write it the way you would explain the tool to a competent colleague who has never seen your process. Three things carry most of the weight: what the thing is, who uses it, and the two or three actions it must support.

Here is the prompt for the example, in full:

Build an equipment checkout tracker for a small video production team. I need to register gear with a name, category, and serial number, check an item out to a person with a due date, check it back in, see everything currently out with anything overdue highlighted in red, and search by gear name or person. Keep a full history per item and save everything to my Puter account.

If your request leaves something genuinely open, you get one short round of questions, at most three, always about the product rather than the technology. Something like whether gear should be checked out to a name you type or to a fixed list of team members.

Answer them if you have an opinion, and skip them if you do not. Skipping is not a penalty: sensible defaults are used, and changing a default later is a one-sentence request. There is only ever one round, so you will not be interrogated.

A checklist appears in plain language, showing what is being worked on. Files are written, the preview fills in, and when the app is ready it is opened for you automatically.

One thing worth understanding, because it changes how much you have to check: after the app is loaded into the preview, it is watched for runtime errors. If anything throws, the error goes back to the AI, which reads the file that broke, fixes the cause, and reloads to check again. It repeats until the app runs clean. So by the time you are told a turn is finished, "it loads and does not crash" has already been verified. What has not been verified is whether it does what you meant. That part is yours.

This is where projects either converge or slowly degrade, and the difference is almost entirely about turn size.

The instinct is to batch: you found six things, so you list six things. Resist it. A turn with six unrelated changes gives you six things to re-test simultaneously, and when one of them is wrong you cannot cleanly undo just that one. Two or three related changes per turn is the sweet spot, and it is faster overall even though each turn feels smaller.

• Group by area, not by priority. "Fix the overdue highlighting and the date format in the same list" is one coherent turn. "Fix the overdue highlighting and add CSV export" is two.
• Say what should be true, not what to change. "Overdue items should be obvious at a glance from across the room" gives better results than "make the text red", because it lets the AI solve the actual problem.
• Point instead of describing. Once the app is real, stop writing "the third column in the checked-out table". Arm the element picker, click the thing, and describe the change. It is faster and it removes an entire class of misunderstanding.
• Use direct visual edits for fiddly work. Spacing, sizes, and colors on a specific element are quicker to nudge with the style controls than to describe. Those edits are kept in their own stylesheet, so later AI changes will not quietly undo them.
• Snapshot before anything structural. Version history records every turn. Before you say "reorganize this into three tabs", know that the current version is one click away.

Occasionally you will ask for the same fix three times and get three versions of the same wrong thing. Repeating yourself louder does not help. Three things do:

• Restate the goal instead of the fix. Describe the outcome you want from scratch, without referencing the previous attempts. You may be anchoring it to an approach that cannot work.
• Restore and take a different run. Roll back to before the attempts and describe the requirement differently. This is almost always faster than pushing through a stuck sequence.
• Isolate it. "Ignore everything else. In the checkout dialog specifically, the due date defaults to today instead of a week from today. Fix only that." Narrowing the scope narrows the search.

The example app saves to your Puter account, which means each person who opens it sees their own data. That is right for a personal tracker and wrong for a shared one: your team needs to see the same gear list.

For genuinely shared state, ask for a serverless worker: "put the gear list behind a Puter worker so everyone on the team sees the same data". The worker runs off the client, holds the shared record, and the app talks to it. For real-time features (people seeing each other's changes as they happen, video, multiplayer), the peer API is the right tool, and it is worth saying so explicitly in the prompt.

For sign-in, ask for a sign-in button using Puter accounts. You get real authentication with no user table to run, and the app can show a clear signed-in and signed-out state rather than surprising people with a popup.

Until you publish, the app runs in a private preview that only you can open. When you are ready, Publish gives it a public address on puter.site that anyone with the link can use. It takes one click, there is no build to wait for, and you can take it down again just as quickly.

If you want to show it to someone before that, share the draft link instead. It points at your work-in-progress preview and updates as you keep building, which is ideal for "does this look right to you?" without committing to anything public.

Publishing does not freeze the project. Keep making changes afterwards and push them live whenever you want.

The project is a folder of ordinary files: HTML, CSS, JavaScript, and Tailwind loaded from a CDN. There is no build step, no framework, and no proprietary format. You can download the whole thing as a zip at any point and host it anywhere that serves static files, or open it in an editor and keep going yourself.

That is worth knowing at the start, not just at the end, because it changes how much you have to trust any single tool. Being able to leave is the thing that makes staying a choice.

The failure mode nobody warns you about is not a broken app. It is an app that has been "nearly done" for two weeks because every session adds one more feature.

Ship it at the point where it does the job you originally described, even if the list of nice-to-haves is still long. A tool people are actually using generates better change requests in a week than you will generate by yourself in a month, and you will build the right next feature instead of the one that seemed exciting on day one.