You cannot build any app with one prompt. You can build a real first version of almost any app if you split the idea into a job, a data model, screens, and proof. Instead of listing that theory again, this post builds one small app end to end so you can copy the moves. The example is a lead-intake tool for a freelancer: capture an inquiry, store it, list it, and draft a reply. Swap the nouns and the same sequence builds your idea.
Name the job in one sentence
Before you open an editor, write the job the app does for one person: "A photographer captures a booking inquiry, sees it in a list, and sends a first reply in under a minute." That sentence sets the whole build. It tells you what data exists, which screens matter, and what "done" looks like. If you cannot write it, you are not ready to build, and no agent can rescue a fuzzy goal.
The founder move here is refusing to start with features. Features come from the job. A vague "CRM for photographers" produces a generic shell with no center; the one-sentence job produces a tool someone can use on Friday.
Write the data model before any screen
Data is the memory of the app, so name it first. For the lead-intake tool, the model is one table:
Lead
id uuid, primary key
name text, required
email text, required
event_date date, nullable
message text
status enum: new | replied | booked | lost
created_at timestamp, default now
Handing the agent an explicit model prevents half the confusion in AI builds. Now the build prompt is concrete instead of hopeful:
Build a Next.js route /leads backed by one Postgres table matching this schema:
[paste the Lead model above].
Create: a public form that inserts a Lead with status "new", and an
authenticated /leads page listing leads newest first with their status.
Use server actions, not a client fetch. Do not add auth providers yet;
stub the session. Show me the migration and the two files you changed.
That last line is the important one. You asked for a receipt, not just code.
Build one screen at a time, and read the diff
Ask for the form first, run it, then ask for the list. Building screen by screen keeps the UI coherent and lets you check mobile early. After each step, read the diff. If the agent touched files unrelated to the request, stop and ask why before you accept anything. A build that quietly edits your auth stub while adding a form is a build you no longer understand.
When the form works, add the reply draft as its own step:
Add a "Draft reply" button on each new lead. On click, call one model
request that writes a short, warm reply using the lead's name and event_date.
Return the draft into an editable textarea; do not auto-send. Show the diff.
One model call, in one spot, doing the fuzzy part. Everything around it stays plain code you can test.
Make the agent prove it works
A serious build prompt ends with verification, because a file changing is not proof the app runs. Ask for commands and their output:
Run the migration and paste the result. Start the dev server, submit the
form with a test lead, and confirm it appears on /leads with status "new".
Paste the terminal output and the row you inserted. List any known risks.
Real receipts for this app are the migration output, the inserted row, and a route returning 200. For non-technical founders, that habit turns code output into a business decision you can actually make: it works, or here is exactly where it does not.
Launch the smallest useful version
Ship the version that completes one job for one person. The photographer can capture a lead and send a reply; that is a product. Save the "team inboxes, calendar sync, payments" dream for after a real user asks. A focused app with one buyer beats a broad app with imaginary ones, and every next feature should come from a customer sentence, not your feature list.
Once the first job holds, add the next one the same way: name it, model the data, build one screen, prove it.
Keep the build
When a build works, save the prompts and the data model as a reusable workflow so the next app starts from your own proven sequence instead of a blank editor. That is the point of Command Center: the receipt from this build becomes the head start on the next one.
Sources and further reading
- Next.js: Server Actions and mutations
- Anthropic: Claude Code documentation
- Google Search Central: Creating helpful, reliable, people-first content
FAQ
Can AI build any app? It can build a real first version of most small apps if you give it a data model, one screen at a time, and a verification step. Large apps with heavy integrations still need to be built as a sequence of small, checked tasks.
What should I give the AI before building? The one-sentence job, the data model, the screen you want first, and the receipt you expect: migration output, a test row, and a route that returns 200.
How do I keep the app from becoming messy? Build one workflow at a time, read every diff, refuse unrelated refactors, and save the prompts that worked so you can reuse them on the next build.