A discovery sprint for an app project is a structured week that takes you from “I have an idea for an app” to “here is exactly what we are building, what it costs, and why”. We run one before every build, because the alternative, diving straight into development with a half-formed brief, is how projects end up £40,000 over budget and six months late. The sprint is deliberately short and cheap on purpose: it exists to kill bad assumptions while killing them still costs nothing but a week of thinking.
This guide gives you the day-by-day process. You can run a lighter version yourself, or use it as a checklist for judging a studio that offers discovery as a paid first phase.
What you need before you start
A discovery sprint only works if a few things are in place before day one. Gather these first or the week drifts.
- A problem worth solving. You should already have some evidence that the problem is real. If you have not done that yet, start with our guide on how to validate a startup idea before you book a sprint.
- Access to real users. You need two or three prospective users available to test on day five. Booking them is the single thing founders forget, and it quietly wrecks the week.
- The right people in the room. Whoever can make decisions must be present for the full week. A sprint where the decision-maker drops in on day four to overrule everything is wasted.
- A hard scope on time. Five days, or three if you compress it. The constraint is the feature, not a limitation. It forces decisions.
Step 1: Map the problem and the user
Day one is about agreement, not ideas. Get everyone in a room and answer three questions out loud: who is the user, what problem are we solving for them, and how will we know if we succeeded. Write each answer as a single sentence and make everyone actually agree to it.
This sounds trivial and is the most valuable day of the week. Co-founders routinely discover on day one that they have been building different products in their heads for months. The problem statement you leave with is the spine of every decision that follows. If you cannot write it in one sentence, you do not understand the problem well enough to build for it yet.
Step 2: Define the critical user journey
On day two, narrow hard. An app can do a hundred things. Your first version must do one thing so well that a user gets real value from it. Pick the single journey that delivers the core promise, from the moment the user arrives to the moment they get what they came for.
Everything else, settings, profiles, admin, the clever secondary features, goes on a parked list. You are not deleting those ideas, you are sequencing them. This critical journey becomes your MVP skeleton, and keeping it ruthless is what keeps the eventual build affordable. Our post on how to scope an app project has a fuller checklist for drawing this line.
Step 3: Sketch and decide the solution
Day three is where you solve the critical journey, then commit. In the morning, everyone sketches their own version of how the journey could work, on paper, badly, in private. Competing sketches beat group brainstorming because they stop the loudest voice from setting the direction.
In the afternoon, decide. Put the sketches up, discuss trade-offs, and choose one approach to prototype. The output is a storyboard of the chosen journey, screen by screen, plus an explicit “out of scope” list. Writing down what you are not building is as important as what you are, because unspoken assumptions are where scope creep is born.
Step 4: Prototype the journey
On day four, build a clickable prototype of the critical journey, and only that journey. It does not need real data or working logic. It needs to look and feel real enough that a user treats it like a product rather than a drawing.
The goal is to fake the experience convincingly in a day. Resist the urge to make it functional. Every hour spent wiring up real behaviour is an hour not spent learning whether the design is right, and you have not earned the right to build real behaviour yet. A flat prototype that a user can tap through tells you almost everything a working build would, at a thousandth of the cost.
Step 5: Test with real users and cost it
Day five earns the whole week. Put the prototype in front of three to five real users, one at a time, and watch. Do not explain or defend it. Ask them to complete the core task and stay quiet while they struggle. Where they hesitate, misread, or give up is where your real build would have failed, except now it is a cheap fix on a prototype.
Five users surface the large majority of usability problems, which is why you do not need twenty. Once you have watched them, turn the validated journey into a concrete feature list and attach a cost and time estimate to it. That estimate is honest because it is built on a scope real users have reacted to, not on a wish list.
What you walk away with
A good discovery sprint ends with four things in hand: a one-sentence problem statement everyone agrees on, a defined critical journey, a tested prototype, and a costed build plan. That package is what makes the difference between a quote you can trust and a number plucked from the air. It is also exactly what a developer needs to give you a tight estimate, which is why we treat it as the first deliverable rather than a sales call.
If you have done this work, writing the brief is almost automatic, and our guide on how to write an app developer brief shows how to turn the sprint output into a document studios can quote against.
What to do next
Run the sprint before you commission anything. A week of structured thinking routinely saves months of expensive rework, and it is the single highest-return activity in the whole project. Whether you run it yourself or with a partner, do not skip it to save five days, those five days are the cheapest insurance in the build.
If you would like us to run a discovery sprint with you and hand back a costed, buildable plan at the end, send us a project brief. Even if you build with someone else afterwards, you will leave with a scope you can trust.
.webp)
.webp)
