How to Write User Stories for Your App Before You Build

Indore, 1 November 2026, most app ideas reach me as a voice note, a handful of screenshots from apps the founder likes, or a long message typed late at night. That is a perfectly good place to start. It is not something a designer can draw from or a developer can plan around, though, so the first real piece of work on any project is turning the idea into user stories.

This post is about how to do that yourself, before you talk to any team. You don't need to be technical. You need to know who will use the app and what they are trying to get done, which you almost certainly know better than we do.

The format we use, and why each part is there

A user story is one sentence: "As a [type of user], I want [to do something] so that [I get some outcome]." Each part has a job.

The user part makes you say who. "Users" is not an answer. A new member, a paying member, a diner, a restaurant owner and an admin all want different things from the same app. The action part should be something a person does, not the name of a feature. "Verification" is a feature. "Prove I am a real person" is something someone does. The outcome is the reason, and it is the part founders skip most often. It is also the part designers and developers rely on most, because it tells them what a good solution looks like when the sentence itself leaves room.

Here are a few illustrations, based on features from two apps we have built: Keen as Mustard, a dating app for Australians, and Lalah, a halal food discovery app for Australia's Muslim community. They are written for this post, not lifted from either client's document.

• As a new member, I want to verify myself with a live selfie and my government ID so that other members can trust I am who my profile says I am.
• As a member, I want to hide my profile from people in my phone contacts so that colleagues and family don't come across me on a dating app.
• As a diner, I want to see prayer times for where I am right now so that I can plan a meal around them.
• As a diner, I want to suggest a restaurant the app is missing so that others in the community can find it too.

Look at the second one. The outcome ("so that colleagues and family don't come across me") quietly settles a design question. If the point is that people you know never see you, then hiding has to work both ways: you don't see them and they don't see you. That is how contact blocking works in Keen as Mustard. A feature list that said "contact blocking" would not have made that obvious. The sentence with a reason does.

Acceptance criteria are where the arguments get settled

A user story says what someone wants. Acceptance criteria say how everyone will know it is done. They are short, plain statements attached to a story, and they are the part that stops a founder and a team from remembering the same feature differently.

Take the restaurant suggestion story above. Its criteria might read something like this:

• A diner can submit a restaurant name and location from inside the app.
• The submission does not appear in the app straight away.
• An admin sees the submission in a review queue and can approve or reject it.
• Once approved, the restaurant shows up on the map and in the list view.

Four lines, and a whole set of questions has answers. A submission does not go live instantly, an admin checks it, and afterwards it appears on the map and in the list. In Lalah, every community submission is reviewed by an admin before it is published. Written down early, the admin review screen is in the plan from day one. Nobody discovers it in month three.

You don't need to write criteria for every story in your first draft. Write them for the stories you have strong opinions about. Those are exactly the ones that cause friction later if they stay in your head.

Write the admin side as its own set of stories

This is the gap I see most in founders' first drafts. They describe the app their customers will use in loving detail, and the admin side gets one line: "admin panel to manage everything".

Both Keen as Mustard and Lalah came with a separate admin panel built in React and Node.js, and in both cases it took real time to build. On Keen as Mustard the admin panel covered verification, weekly giveaways, subscriptions and moderation. On Lalah it was where restaurant submissions got checked before anyone else saw them.

My rule of thumb: any user story where someone creates, reports or pays for something probably needs a matching admin story. A member reports another profile, so somebody has to see that report and act on it. A diner suggests a restaurant, so somebody has to approve it. Write those as their own stories, in their own section. "As an admin, I want a queue of new restaurant submissions so that nothing goes live before someone has checked it."

If there is a third type of user, such as a venue owner or a practitioner, give them their own section too. Or decide, in writing, that version one handles them outside the app with a spreadsheet and a phone call. Both are fine. Leaving it undecided is not.

What to leave out of version one

Once the stories are written down, go through them one at a time and ask a single question: can the app launch without this? Not "would it be nice". Launch.

The stories that tend to fall away are the ones that make an app feel complete rather than the ones that make it work. Loyalty points, a web version alongside the mobile app, several sign-in options when one would do, multiple languages, a recommendation engine. Some of them will matter later. Very few of them matter before you know whether people use the core of the product.

I will admit the rule cuts both ways. Keen as Mustard ended up at 100+ screens, which is large for a first release. Verification, contact blocking and privacy controls were the reason a member would trust the app at all. Cutting them to save time would have produced a smaller app nobody wanted to sign up to. Lalah, at around 40 screens, had a tighter core: find a restaurant, see its details, get there. The right size for version one depends on what the product has to prove.

Don't delete the stories you cut. Move them to a "later" list. It keeps good ideas from getting lost, and it lets the developers avoid building the first version in a way that makes those later stories harder. Our page on MVP development for startups goes further into how we scope a first release with founders.

Why our proposal comes with a user story document

After the free discovery call, we send a proposal within 3 to 5 days. It covers scope, timeline and milestones, and it includes a user story document. If you have written your own draft, we start from yours. If you haven't, we write it from what you told us on the call.

The document is there because everything else is built from it. The screens our lead designer draws come from the stories. The timeline comes from how many stories there are and how much backend work sits behind each one. When a founder asks "was this in scope?", the answer is in that document, not in two people's memories of a call.

Design is the next step, and nothing gets coded until you have signed off every screen in Figma. The stories make that review faster, because you can hold each screen up against a sentence and check it does what the sentence says. The full sequence is on the app development process page.

Founders sometimes find the document dull. I understand. It is a long list of sentences that all start the same way. It is still the easiest point in the whole project to change your mind. Adding a story at proposal stage costs a few minutes of typing. Adding it after design sign-off means new screens, new testing and a conversation about the timeline.

A first draft you can write this week

Start with a list of every type of person who will touch the app, including you and your staff. For each one, write five to ten stories about what they will do in their first week with it. Give every story an outcome, even if it feels obvious. Then mark the ones the app cannot launch without, and add acceptance criteria to anything you feel strongly about.

The format doesn't have to be perfect. A rough page of honest stories is far more useful on a first call than a polished pitch deck. If you would like us to look at yours, send it through the contact page and bring it to the discovery call.