App Discovery Workshop: The Questions We Ask Before Building
- Apps Value
- 0 Comments
The Questions We Ask Before Building Any App
Every project we take on starts with an app discovery workshop, and most projects in this industry go wrong before anyone writes code. These are the questions we actually ask in that room, and the reason each one exists.
We are publishing them because they are not a secret weapon, they are a filter. A founder who answers these questions in writing will get better quotes from every agency they talk to, ours included, and waste less money either way.
Assumptions are the most expensive part of any build
The app discovery workshop is a session where we take a brief apart and rebuild it as a set of answered questions. Skipping this step does not save time, it moves the discovery into month two of the build, where every answer costs ten times more.
The goal surprises people: we are not trying to understand your app. We are trying to understand your business well enough to know which app not to build. The feature list usually shrinks in that room, and the product gets better every time it does.
The questions, and why each one exists
The questions look simple. They are not, and the order matters: user first, product second, money third, scale fourth, success last. Answering them out of order is how feature lists get written before anyone knows who the app is for.
The user
- "Describe the typical user. How old are they, what do they do?" Not a persona template, a real picture. The answer drives everything downstream: design language, onboarding length, how much the interface can assume. An app for a 24 year old courier and an app for a 55 year old site manager are different products even when the feature list is identical.
- "Where will they use it: at a desk, in the field, on the move?" Context of use is a design requirement in disguise. An app used with gloves on a rooftop, one handed on a tram, and one used calmly at a desk are three different interfaces for the same feature list.
- "Will older people use this app?" This one question changes font sizes, contrast, touch targets, and how much of the flow can rely on conventions younger users know by heart. Asking it in the workshop costs nothing. Discovering it after launch costs a redesign.
The core
- "What is the core of the app?" One answer, one sentence. If the core takes three sentences to describe, the product is not understood yet, and no estimate given at this point is worth the paper.
- "Which features are must have, and which are not?" Everyone answers "all of them" at first. Then we go feature by feature, and the honest split emerges. The must have list becomes version one. The rest becomes the roadmap, not the budget.
- "Which functionality delivers the most value to users?" This is a different question than which feature the founder likes most, and the difference is where budgets get wasted. The highest value functionality gets the most design and engineering attention, by decision, not by accident.
- "What makes users come back?" A returning user is worth more than a newly acquired one, so whatever drives the return visit is the most valuable thing in the product. If nobody in the room can answer this, that is the most important finding of the whole workshop.
The money
- "What is the business model, and is there one?" Subscriptions, commissions, one time purchases, or an internal tool that earns by saving hours. Each model shapes the architecture: payments, roles, billing logic. And "we will figure it out later" is an answer too, it just means version one should be built to keep the options open, which is itself a scoping decision.
- "Who actually pays: the user, their employer, or someone else?" The payer and the user are often two different people with two different definitions of value. The user wants the app to be effortless, the payer wants it to be measurable, and the product has to satisfy both or it gets cancelled at renewal.
- "How much are users willing to pay for this?" The answer calibrates everything: a product users pay 5 euro a month for and a product companies pay 500 for need different levels of polish, support, and onboarding. It also tests whether the value story is real or hoped for.
The scale and the risk
- "What is the expected user growth?" A hundred users in year one and a hundred thousand are different engineering problems, and building for the second when you have the first is one of the most common ways startups overspend. The honest growth number lets us build for the real curve, with an architecture that can grow when the curve does.
- "Does it need to work offline or in poor connectivity?" One sentence in a brief, weeks in a codebase. If the user is in the field, in a basement, or on the water, the honest answer changes the architecture and the estimate, so it has to fall in the workshop, not in the sprint.
- "Will the app process sensitive data?" Health records, payments, personal documents, location history. The answer decides security architecture, compliance requirements, and where data can live. This cannot be bolted on later, so it has to be on the table before the estimate.
The finish line
- "How do we phrase the Definition of Done?" Written down, together, in the workshop. "Done" means something different to a founder, a developer, and an investor, and every dispute we have ever seen between a client and an agency traces back to this sentence not existing.
- "Who on your side owns the product after launch?" An app without an owner stops evolving the day it ships. Knowing who collects feedback, prioritizes fixes, and makes the call on version two tells us how to hand the product over, and whether a maintenance arrangement makes sense at all.
- "What are the KPIs, and what will you call success?" Downloads, retention, bookings processed, hours saved. Whatever it is, it gets named before the build starts, because a project without a success metric cannot succeed, it can only end.
What the answers turn into
The workshop is not a conversation that evaporates. The answers produce artifacts, and they are yours regardless of whether you build with us.
A scoped feature list with the cuts on record
The must have list, with everything that was cut and why. This document makes every quote you collect afterward comparable, because every agency is finally pricing the same thing.
A feature by feature estimate
Each feature gets its own number, so you see where the budget goes and can trade scope for cost with open eyes.
A timeline and a Definition of Done
Because the core, the risks, and the finish line are on paper, the timeline follows from scope instead of optimism, and both sides know what "done" means before anything starts.
Sometimes: the advice not to build
If the answers show the problem is small or a ready made tool closes the gap, we say so, and the workshop is where the project ends. If we are not the right fit, you hear it there, not in month three.
If you want to see how this thinking plays out in a full build, the same process sits behind every project in our case studies, and the scoping philosophy is the backbone of how we approach MVP development for startups.
Run these questions on your project
One intro call. Walk us through what you want to build and we will work through these questions with you. You leave with a clear picture of the product, and if the honest answer is that you should not build yet, you will hear that too.
