App Discovery Workshop: The Questions We Ask Before Building
- Apps Value
- 0 Comments
App Discovery Workshop: The Questions We Answer Before Anyone Writes Code
Most app projects go wrong before a line of code exists. The discovery workshop is where a brief gets taken apart and rebuilt as a set of answered questions, then turned into a scoped feature list, a feature by feature estimate, a timeline and a written definition of done. The output is yours whether or not you build with us.
- Discovery workshop
- Product scoping
- Fixed price
- For founders and owners
- A working session, not a sales call. We work through the user, the core, the money, the risks and the finish line, in that order, and write down every answer.
- It produces documents you own. A scoped feature list with the cuts on record, a feature by feature estimate, a timeline and a written definition of done.
- It makes every other quote comparable. Take the same document to three agencies and they finally price the same thing.
- It can end with the advice not to build. If a ready made tool closes the gap, that is where the project stops, and it costs you a workshop rather than a build.
Why does discovery come before the estimate?
Skipping this step does not save time. It moves the discovery into month two of the build, where every answer costs several times more, because by then the decisions are already sitting in a codebase.
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.
A brief describes the app someone imagined. The workshop finds the app the business actually needs.
Who is this for, and when is it not worth it?
It fits a company or founder with a real operation or a real market behind the idea, a budget that has a ceiling, and a date that has a reason. It is the right first step when several agencies have quoted wildly different numbers, because that spread almost always comes from an unclear brief rather than from margin.
- Not worth it when the answer is a ready made tool. If an off the shelf product covers the workflow with configuration, we will say so on the first call, before anyone books a workshop.
- Not worth it when the direction changes weekly by design. Exploratory work with a scope that moves every sprint needs a different arrangement, and a fixed scope fights it.
- Not worth it without a decision maker. The workshop produces decisions. If the person who can approve them is not in the room, it produces a document no one can sign.
What questions does the workshop actually ask?
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 design language, onboarding length and 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? 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 the room has no answer to 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 payments, roles and billing logic. Deciding later is an answer too, and it means version one has 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 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 a few euros a month for and a product companies pay hundreds 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 companies overspend. The honest 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 rather than in a sprint. What the three versions of offline actually cost is in what offline means in a mobile app.
- 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 belongs 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 most disputes between a client and an agency trace back to this sentence not existing. What it has to contain is set out in what a fixed price contract has to say.
- Who on your side owns the product after launch? An app without an owner stops evolving the day it ships. Knowing who collects feedback, prioritises fixes and makes the call on version two tells us how to hand the product over.
- 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 do you leave the workshop with?
The workshop is not a conversation that evaporates. The answers produce four 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, plus everything that was cut and the reason it was cut. This is the document that makes every quote you collect afterwards comparable, because every agency is finally pricing the same thing.
Why it mattersMost of the gap between two quotes comes from an unclear brief, not from margin.
A feature by feature estimate
Each feature carries its own number, so you can see where the budget goes and trade scope against cost with open eyes rather than negotiating a lump sum.
Why it mattersA single total tells you nothing about what to cut when the budget is tight.
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.
Why it mattersA project without a defined end has no line between what you paid for and billable extra.
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 rather than in month three.
Why it mattersThe cheapest project is the one that never should have started.
How does the workshop run?
It is a short, structured sequence. Most of it happens in a few days, and it ends with documents rather than with a conversation to be remembered.
Intro call, 30 minutes
You describe the operation or the product and what is driving the date. We say whether a workshop is the right next step, and sometimes the answer is that it is not.
Preparation
We ask for the material that already exists: a week of real orders or jobs, the spreadsheet or notes people keep on the side, and access to whoever does the work day to day.
The working session
We go through the questions above in order, with your decision maker in the room. The feature list gets cut here, with every cut written down and justified.
The documents
You receive the scoped feature list, the feature by feature estimate, the timeline and the definition of done. If you continue with us, this becomes the annex the fixed price is attached to.
The workshop is a paid, standalone piece of work, and its fee and how it is treated if you continue into a build are on the pricing page. The commercial model it feeds into is described under fixed price app development.
If you already have the material, send it over by email instead of booking a call. We reply with what a workshop would cover in your case and what we would expect to cut from version one.
Send your brief by emailWho is answering this?
- CompanyApps Value, mobile app development agency
- LocationKraków, Poland
- Markets servedUnited States, Western Europe, Nordics
- Experience6 years, 19+ projects delivered, 13+ positive client reviews
- TechnologiesFlutter, React Native, NestJS, Supabase, PostgreSQL, AWS, Google Cloud
- Engagement modelsFixed price contracts and dedicated development teams
FAQ
How long does an app discovery workshop take?
The working session itself runs a few hours with your decision maker in the room. With preparation and the documents that follow, the whole thing usually spans a few days to two weeks, depending on how much access we need to the people who do the work.
Is the workshop paid, and what happens if we continue?
It is paid and it stands alone, which is what keeps the advice honest. How the fee is treated if you go on to build with us is set out on the pricing page.
Can we take the output to another agency?
Yes, and some clients do. The documents are yours. A scoped feature list with the cuts on record is exactly what makes competing quotes comparable, which is the main reason the workshop pays for itself even if you build elsewhere.
Do we need a specification before the workshop?
No. A detailed specification written without a software team involved often makes things harder. What helps is a week of real orders or jobs, the list of things people do by hand today, and the honest reason behind your date.
Who needs to attend?
One person who can approve scope, plus someone who does the work day to day. An hour with a technician, dispatcher or operator is worth more than a week of documents, because documents describe the process as designed rather than as it runs.
What does the workshop lead to?
A written scope with counts, and a fixed price attached to it. The four clauses that decide whether that price holds are covered in what a fixed price app development contract has to say.
Does this work for operational software rather than a consumer app?
Yes, and those projects benefit from it most, because coverage rules, offline work and integration with an existing system decide the scope. The vertical specifics are on our field service app development and custom HVAC software development pages.
Related guides
Run these questions on your project
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.
30 minutes, no preparation needed.
