In this guide
You do not need a technical specification to have a useful conversation with a developer. You need a clear description of the person you are helping, the task they want to complete, and what a successful first version would let them do.
A short brief helps the developer ask better questions and prepare a quote with fewer assumptions. Use the template below as a starting point. If an answer is unknown, say so: an open question is more useful than a feature added just to make the document look complete.
Key takeaways
Start with one person and one problem
Name your first audience narrowly enough that you can find people to speak with.
Describe the journey in ordinary language
Write the steps in the order someone will take them.
Copy this brief and fill in the gaps
Keep the first draft short.
Separate launch requirements from later ideas
For the example portal, invited clients and assigned plans may be essential.
Start with one person and one problem
Name your first audience narrowly enough that you can find people to speak with. ‘Busy people’ is hard to design for. ‘Independent Pilates instructors who send weekly practice plans to existing clients’ tells the builder much more.
Describe how that person handles the task today. Perhaps they send PDF plans through messages and lose track of which version each client received. That current workaround explains the problem more clearly than asking for a dashboard. Include what you have actually observed and distinguish it from assumptions you still need to test.
Describe the journey in ordinary language
Write the steps in the order someone will take them. For the Pilates example: the instructor invites an existing client, assigns a plan, and sees whether the client has opened it. The client accepts the invitation and views the current plan on their phone.
Then name the exceptions that matter. What if an invitation expires? Can a client see another client’s plan? What happens when an instructor uploads the wrong file? These questions reveal work that a list of screen names misses. You can ask the developer to propose sensible defaults rather than designing every detail yourself.
Copy this brief and fill in the gaps
Keep the first draft short. One or two sentences for each prompt is enough to start a scoping conversation.
- Audience: The first people who will use this are…
- Problem: Today they do this using… The difficult part is…
- Core result: After using the first version, they should be able to…
- Journey: The main steps are… Someone with an admin role must also be able to…
- Platform: I expect people to use it on… I think this matters because…
- Content and accounts: I already have… I still need help preparing…
- Connections: The product needs to exchange information with…
- Boundaries: Version one must include… These ideas can wait…
- Constraints: My budget, deadline, feedback availability, and open questions are…
Separate launch requirements from later ideas
For the example portal, invited clients and assigned plans may be essential. Public profiles, a social feed, and a marketplace could wait. This boundary lets a developer price the useful first workflow without treating every possible future direction as a launch requirement.
Avoid putting a fixed deadline next to an unlimited feature list. If the date matters, explain why and ask which scope can realistically fit. If the workflow matters more, ask for a schedule based on that workflow. Note which accounts, content, and approvals you can provide before kickoff.
Use the brief to get a written proposal
Ask the developer to reflect the agreed brief back in a proposal. It should identify the deliverables, exclusions, acceptance checks, project fee, payment milestones, running costs, and handover. Resolve material differences before work starts.
At Build with Kat, the first conversation is a free scoping call. Bring this draft, examples of the current workaround, and the questions you have not answered yet. If the project fits, the next step is a fixed quote for an agreed first version.
Related app guides
Ready to build?
Ready to scope your first version?
Bring the idea, audience, and current workaround. I will help decide what belongs in version one, what should wait, and whether a fixed-price build makes sense.
See app build options