Guide
A non-technical founder briefs a developer with a written PRD, not a walkthrough. State who the product is for, the job it must finish, the steps in that job, what this version will not include, how you will know it worked, and any constraints you already know. Hand over that document and let the builder choose the tools.
Describe the idea and get a PRD and build plan. No card required for the first one.
Try FounderBriefHand them a document they can read without you in the room. A call can explain tone. It cannot be the spec, because the spec has to survive after the call. The document names the user, the job, the steps, the non-goals, the signal that the version worked, and the constraints you already know. That is a PRD. A slide of the logo and a list of adjectives is not.
Use the PRD template for startups if you want the sections laid out as blocks you can fill. You do not need to know how the product will be built. You need to know what the user will be able to finish, and what you are refusing to include. If a line is something only you understand, rewrite it until a stranger could test it.
Talk about what the user sees and does. "They open a link on their phone and tap confirm" is a product sentence. "Use this framework and this database" is a solution sentence, and it is the developer's to make unless you already have a system they must fit. When you do have a constraint, say it as a constraint: the clinic already pays for a calendar that has to stay the source of bookings, or the first version has to run in a browser because you will not ship an app store release.
Separate facts from preferences. A fact is "we already collect phone numbers and we are not allowed to text them yet." A preference is "I like how that other product looks." Put facts in the brief. Mention a preference once, and let the developer ignore it if it fights the job. A brief that is mostly visual references gives you a costume of another product, not the flow your user needs.
Answer six things in writing, even if the answers are short. Who is the user. What do they do today. What must they be able to finish in this version. What will this version not do. How will you know the version worked. What is already decided about platforms, sign-in, payments, data, and other systems. If you cannot answer one, write the question. Do not fill it with a guess and hope the developer notices.
Bring the real workaround to the call if you can: the spreadsheet, the text thread with names removed, the email you send every Friday. A developer estimates better from an artifact than from a metaphor. Walk the steps once, in order, and then stop talking. Ask them to restate the job. If their restatement adds a feature, decide in the meeting whether it is in or out, and write the decision into the doc before you hang up.
Ask for an estimate of the first slice, not of the whole company. The first slice is the shortest sequence that lets the user finish the job. If the estimate is larger than you can pay for or wait for, cut steps, not quality adjectives. "Make it faster to build" without removing a step is not a cut. Removing "team invites" is a cut. Update the non-goals so the smaller version is the version you both think you agreed to.
Define done as the user's outcome, plus the obvious failure you will not accept. "A locum can confirm from the link, and we can see who confirmed" is done. "Pixel perfect" is not a finish line you can share. Agree how you will look at the work: a staging link you click through against the steps in the brief. Written acceptance beats a feeling that it is not quite right yet.
Leave the tools, the file structure, the libraries, and the shape of the database, unless a constraint forces one of them. Also leave small interface choices that do not change the job: the exact control, the spacing, the empty-state illustration. Reviewing those as if they were requirements burns the time you meant to spend on the flow.
Do not leave the scope. Scope is yours. If you say "you are the expert, just build what makes sense," you will get a reasonable product for a user the developer imagined. That can be a good product and still the wrong one. The brief is how you stay the person who decides. The developer is the person who finds a way to build the decision. Both jobs are real. They are not the same job.
When a new idea shows up, write it down away from the current slice. Once a week, decide whether it replaces a step, waits, or dies. If it replaces a step, change the brief and accept that the estimate changes. If it waits, it goes on the later list. Sending it in a chat message and also expecting the old date is how briefs rot. The document in front of the developer should match the version you think you are buying.
If you are also prompting a coding tool yourself, keep one spec for both the person and the tool. The page on a spec you can paste into Cursor, Lovable, Bolt, or v0 is the same decisions, aimed at a generator. You can try FounderBrief to get a first draft of the brief from a plain description of the idea. The first generation is free. Edit it until you can read every line out loud to the developer without apologizing for it.
No. You need the user, the job, the steps, the non-goals, the success signal, and the constraints you already know. The developer chooses how to build that, and tells you when a constraint makes a step expensive.
A call helps, and then the decisions have to land in the document. If it only lives in the recording, you will disagree later about what was in scope. Write the outcome and the non-goals before you estimate.
Write the question. "I do not know if we are allowed to text locums" is more useful than a fake decision. The developer can tell you what changes if the answer is no.
A free startup PRD template you can copy: user, problem, scope, non-goals, stories, metrics, constraints, and the order you will build it.
Write a short spec before you prompt Cursor, Lovable, Bolt, or v0: user, screens, data, non-goals, and how you will check the result.