Guide
Write the PRD before you prompt Cursor, Lovable, Bolt, or v0. Name the user, the job, the screens in that job, what the first version will not do, and the data each step reads or writes. Then paste that spec into the tool. A coding agent follows the prompt it is given, so an unclear spec becomes an unclear app.
Describe the idea and get a PRD and build plan. No card required for the first one.
Try FounderBriefCursor, Lovable, Bolt, and v0 are different products, and each one changes. This guide does not rank them and does not restate their prices or feature lists. Read each product's own site for that. What they share, for a founder, is that you steer them with language. The model fills gaps you leave. If you did not say who the app is for, it will invent a user. If you did not say what to skip, it will add screens.
A spec written first is a constraint on that invention. You are not trying to produce a perfect prompt. You are trying to produce a page you can compare the generated app against. When the result drifts, you edit the spec and prompt again, instead of arguing with a chat thread you can no longer reread. The PRD template for startups is a blank for that page.
Decide the user, the one job, and the outcome you could check. Then list the screens that job needs, in the order the user meets them. A booking product might be: a list of open shifts, a link the other person opens, a confirm button, and a status back on the list. That is enough to start. A settings area, a team switcher, and a chart are not part of the job until a step says they are.
Write the data each screen reads and writes, in plain words. "The list shows today's shifts. Confirming a shift stores who confirmed and when." You do not need a schema. You need to stop the tool from inventing accounts, roles, and tables the job does not use. Also write the non-goals in the same note, before you are tempted by a generated screen that looks finished.
Describe each screen as a job step, not as a visual. Say what is on it, what the user can do, and where they go next. "A page with the open shifts, a control that copies a link, and the name of the person who confirmed" is a spec. "Make it clean and modern, with a sidebar and cards" is a style request, and the tool will satisfy the style even when the job is wrong.
Keep the first prompt to one flow. Ask for the happy path that finishes the job. Empty states, errors, and edge cases can be a second prompt after the happy path exists and you have clicked through it. If you ask for every state up front, you get a wide app that does not complete the one task. Paste the flow as a numbered list so the order is hard to miss.
Put the non-goals in the prompt, not only in your head. Name the things a generator likes to add: extra roles, a billing page, notifications, a dashboard of charts, social login, and a marketing homepage. Say which of those are out for this pass. "Do not add authentication" is a valid line when the first test is a single user on one machine. You can add sign-in when a second person needs to use it.
Also say what "done" means for the pass. "Done when I can create a shift, open the link in another window, confirm it, and see the status change on the list." That sentence is the test you will run when the tool stops. If the generated app cannot do that sentence, the pass failed, even if the interface looks complete. Do not start a second feature to avoid looking at the failure.
Click the flow before you read the code, if the tool gives you a running screen. Try the steps in the spec, in order, with the data you named. Write down every place the app asks for something the spec did not, or skips a step the spec required. Those notes are the next prompt. "Remove the team invite. The spec has one user in this version" is a better follow-up than "make it better."
Then look at what got stored. If the spec said a confirmation stores a name and a time, check that those are the fields, not a pile of unused profile columns. You are allowed to keep a generated choice that does not contradict the spec. You should delete a generated feature that adds a job you did not write. The spec stays the source. The chat is not.
Stop when the same mistake appears twice. That usually means the spec is ambiguous, not that the tool needs a longer scolding. Change the sentence that was misread, then prompt from the revised spec. If you cannot tell whether the app matches, the outcome line is too vague. Rewrite the outcome until a click either passes or fails.
A coding tool is not a substitute for the conversation with a builder when the product is unclear. If you are about to hand the result to a person, read how a non-technical founder briefs a developer and send the spec, not only the repo. You can try FounderBrief to draft that spec from a short description before you paste anything into a coding tool. The first generation is free. Cut it until you can defend every line, then prompt.
The products differ, and their docs are the place to check current limits. The spec can stay the same: user, job, screens, data, non-goals, and a sentence for done. Adjust the prompt to whatever the tool asks you to paste.
Name a stack only if you already have one and the tool will touch it. Otherwise state constraints, such as a web app with no login in the first pass. Let the tool's default stand unless it blocks the flow.
Long enough to include the flow, the data, the non-goals, and the done sentence. A page is enough. A vague paragraph produces a vague app, and a ten-page prompt gets summarized in ways you did not choose.
A free startup PRD template you can copy: user, problem, scope, non-goals, stories, metrics, constraints, and the order you will build it.
Brief a developer with a written PRD: the user, the job, the steps, the non-goals, the success signal, and the constraints you already know.