How to build an app with an AI coding agent, from idea to shipped

What is the workflow from idea to shipped app?

An AI coding agent is a tool that turns written instructions into working code. Terminal and editor tools such as Claude Code, Cursor and Codex work inside your project folder, while browser builders such as Lovable generate and host the app for you. They differ in where they run and how much they do on their own. The workflow below does not depend on which one you pick, because the hard parts are decisions the tool cannot make for you.

1. Brief. One paragraph: who the user is, what problem they have, what finished looks like.
2. Scope. Cut the idea down to one user and one complete outcome.
3. Build prompt. Turn the brief and scope into a specification the agent can follow.
4. Plan first. Ask for a plan and questions, not code. Correct the plan.
5. Small verified steps. One piece at a time, each one run and checked before the next.
6. Tests. Have the agent write them, then read them to see what they actually prove.
7. Review the diff. Read what changed, not what the agent says it changed.
8. Deploy. Put it in front of one real person, with secrets and payments handled by you.

Each step exists because of a specific way the process fails. Skip the brief and the agent invents the product. Skip the plan and a wrong assumption gets built into twenty files before you notice. Skip the review and you ship code nobody has read.

How do you write the brief and cut the scope?

Start with a paragraph a stranger could understand: who is stuck, at what moment, and what they do today instead. If you cannot write it, the idea is not ready to build, and a coding agent will not fix that. The guide to validating an app idea covers how to test the problem before you spend a weekend on it.

Then cut. A first version has one user, one input, one result and one way to see that it worked. Everything else goes on a “later” list that you do not show the agent, because an agent given a long wish list will try to build all of it. The guide to scoping an MVP shows how to separate essentials from assumptions, and the MVP scope planner walks through it with your own idea.

What goes into a build prompt?

A build prompt is the brief turned into instructions. It names the user and problem, the core flow in numbered steps, what data is stored and who can see it, the constraints, what is out of scope, the failure states, and checks you will perform. The longer treatment is in how to write an app build prompt; the template below is the short version.

Build a first version of [app name].

User: [one specific person and the situation they are in].
Problem: [what they do today and why it fails].
Success: [the one result they can achieve].

Core flow:
1. [starting action]
2. [main operation]
3. [result, save or export]

Data and access: [what is stored, where, and who may read or change it].
Constraints: [stack, devices, services you allow, budget limits].
Do not include yet: [login, billing, teams, analytics, anything on your later list].
Failure states: [empty input, invalid input, network failure, third-party service down].

Acceptance checks:
- [a happy-path check you can do in two minutes]
- [a check that data survives a reload]
- [a check for one failure case]

Before writing code: list your assumptions and any blocking questions, then give me a step-by-step plan and wait for my go-ahead.

Can you start from an idea someone else posted?

Yes, that is what this board is for. Every idea page on Post your build ideas has a generated build prompt that contains the whole description, plus buttons to copy it or open it in Claude Code, Codex or Cursor. You can paste the same text into Lovable or any other builder.

Treat it as a first draft, not a finished specification. The generated prompt asks for the smallest version that delivers the core value, asks the tool to state its stack before coding, and asks it to handle empty, error and offline cases. It knows nothing about your skills, your hosting or the audience you have in mind. Edit it using the template above: add the acceptance checks, name what you will not build, and set your constraints.

Also remember that the person who posted the idea may never have tested demand. Run a quick check of your own first. You can browse the board for something to build or paste a description into the Idea Checker, which points out missing details, then fill those gaps in the prompt.

Why ask for a plan before code?

A plan is cheap to correct and code is not. When you ask for a plan first, the agent shows its assumptions: which framework, where data lives, which screens exist. You can catch “it chose a database you cannot host” or “it added login” before any file exists.

Ask for four things in the plan: the stack and why, the list of screens or modules, the order of work in steps small enough to check in minutes, and the questions it could not answer from your prompt. Answer those questions in writing. If the plan includes something on your “do not include” list, say so and have it revise the plan, not just skip the item in code.

Several agents offer a mode where the tool proposes without editing files. Use it when it exists. When it does not, the sentence “do not write or change any files until I approve the plan” does most of the same work.

How do you build in small, verified steps?

Take the plan one step at a time and finish each before starting the next. A step is done when you have run it and seen it work, not when the agent says it is done. Agents report success on code that does not start, so the habit that matters is running the thing yourself.

• Size. One step should change a handful of files and be checkable in under five minutes. If it is bigger, split it.
• Order. Build the path through the whole flow first, even if it is ugly, then improve each part. A working skeleton shows you the real problems early.
• Evidence. After each step, run the app or the tests and look at the result. Paste any error back verbatim instead of describing it.
• Version control. Commit after every step that works. When a later step goes wrong, you can return to the last good state in one command.
• One change at a time. If a step breaks something, fix that before adding anything new. Stacking changes on a broken base makes the cause impossible to find.

How do you test and review what the agent wrote?

Ask the agent to write tests for the acceptance checks in your prompt, then read the tests. A test that only checks that a function returns something proves little. A good test names a behavior: “after adding three items and reloading, three items are still there”. If the tests do not match your checks, say which are missing.

Review the diff, meaning the actual lines added and removed, before you commit. You are looking for things the agent tends to get wrong without announcing it.

Finish with a manual pass that no test replaces. Use the app as a new user would: an empty form, a very long input, a reload mid-task, a phone-width screen. If the app stores records for more than one person, try to read one user’s data while signed in as another.

What should you deploy, and what should you never delegate?

Deploy early, to a hosting service you chose, and show it to one real person who has the problem. A deployed app that two people use teaches more than a polished one on your laptop. Keep configuration out of the repository: keys and passwords live in the host’s environment settings, and the agent never needs to see their values.

Some work should stay with you, or be reviewed line by line if you do hand it over:

• Secrets. Do not paste keys into prompts or let them be committed. Rotate any key that has ever appeared in a chat or a commit.
• Payments logic. Charging, refunds, webhooks and access after payment. A bug here costs real money and trust, so read every line and test with the payment provider’s test mode before going live.
• Authentication and permissions. Who can read and change what. Test with two accounts.
• Deleting data. Migrations and cleanup scripts that cannot be undone. Run them against a copy first.
• Legal and privacy claims. What your site says about data and cookies must match what it does.

If you built something from an idea on the board, open that idea’s page and use the “Already built this? Link your app” form. Links are published unverified, so be accurate about what you shipped. If you are still looking for what to build, the list of Claude Code project ideas has projects sized for a first build.

Which AI coding tool should you use?

The workflow above works with any of them, so the choice matters less than finishing a small project end to end. Tools differ in where they run (terminal, editor, browser), how much they ask before acting, and how much setup they expect. For a side-by-side look, read Claude Code vs Cursor vs Lovable. If you use Claude Code specifically, how to build an app with Claude Code covers its commands and project instructions.

Pick one tool for your first project and stay with it until you ship. Switching halfway means re-explaining the project, and you learn nothing about whether the problem was the tool or the brief.