The requirements for your app are already in your head. What it does, who logs in, what happens when someone taps the button. What you’re missing is the app requirements document: the page that turns what you know into something a developer can build from.
That document is the blocker. Not because the requirements aren’t there, but because writing them down in a form someone can build from is a separate skill, and it’s the one most people are worst at.
So the blank page sits there. The idea is clear the moment you describe it out loud, and it goes vague the moment it has to become a spec.
Here is the move that gets you past it. You don’t write the document. You answer questions, and the requirements get written from your answers.
What a requirements document is actually made of
Before anyone builds your app, five things have to be pinned down: what it’s for, who uses it, what each of those people can do, what must never happen and what “done” means. Every app requirements document is some version of those five, whatever template it hides inside.
The questions below fill them in. This is what a scoping conversation covers, laid out so you can work through it yourself. It’s not a fixed form and it’s not a checklist you complete in order. A real conversation adapts, drops what doesn’t apply to your app and asks the follow-up your project needs. Read them as the shape of the thing. You’ll see exactly what a buildable requirement set is made of, whether or not you ever hand your answers to anyone.
What the app is for
Start with the reason it exists, before any screen or feature.
- What does someone use this app to get done that they can’t do today?
- If it did one thing well and nothing else, what is that one thing?
- A month after launch, what has to be true for it to have been worth building?
Who uses it
Every login is a different app behind the same screen. Name them all.
- Who logs in? List every kind of person. An admin and a regular user are two different applications sharing one login page.
- What can each of them see that the others can’t?
- Does anyone use the app without an account at all?
What each user can do
This is the section a blank template leaves emptiest, and the one that decides the whole build.
- For every role, name the actions in plain verbs. A coach adds a student. A student logs a session.
- Which of those actions create data, which change it and which delete it?
- After each action, where does the person land and what do they see next?
What must never happen
The requirements you leave out here are the ones that become incidents later. Say them now.
- What data must one user never see that belongs to another?
- What action must never run twice, even when someone double taps or reloads the page?
- What is the app not allowed to do, even when a user asks it to?
What “done” looks like
A feature isn’t done because it exists. It’s done when you can describe the check it passes.
- How do you know a feature works? Describe the click and the exact result you expect.
- What happens when someone does the wrong thing: an empty form, a wrong password, no connection?
- What has to be true before a real user is allowed to touch it?
Answer those and you haven’t written a document. You’ve said what you already know out loud, in order. The document is what someone else builds from your answers.
Who asks the questions, and who writes it down
At TalkIDE, Vera asks these questions. She runs the requirements conversation with you directly, in plain language. She asks the follow-ups a blank field never will. You said a student logs a session. Can a coach see it? Can the student edit it later? What happens to it when the account closes? Every answer is a requirement.
You don’t arrive with a spec. You arrive with what you want, in whatever order it comes out. The conversation puts it in order.
When you’re ready, you hand the project off. Mara’s team takes it from there, and Iris, the analyst on that team, turns the conversation into structured, testable requirements before anyone writes a line of code. Testable means each requirement names a result you can check. Not “users can log sessions” but “a logged-in student can save a session and see it in their history, and no other student can see it.”
Vera is the default path, not a toll gate. If you already know exactly what you want, you can skip the conversation and start straight with Mara’s team.
This is the same conversation we walk through in how to describe an app idea without writing a spec. Vera also brings back a clickable mockup you can react to, so you approve something on a screen instead of signing off on a page of text.
Why a conversation beats a blank template
A blank template asks you to already know what belongs in every field. That’s the exact problem you started with.
A conversation asks the question a template can’t. Type “users can log a session” into a template and it accepts the line without a word. Say the same thing to Vera and the follow-ups come: edit it later, delete it, who else can see it, what happens to it when the account closes. Each answer is a requirement you’d have left out of the document you were dreading.
This is really how to write app requirements without writing them yourself. It’s also the difference between a real requirements set and a PRD you draft alone at midnight and hope you covered. The finished document comes out the same shape either way. What changes is who does the remembering.
You do not need a template. You don’t need to know the format. You answer good questions, then you check the requirements that come back.
See how a project gets scoped.
The Mara team.