)
)
Here's a scene we know all too well.
A founder walks in (digitally, obviously). Slides ready, features named, app already half-built in their head. They're three minutes into the pitch when it lands: there's a beautifully designed solution here for a problem nobody's actually defined.
It happens all the time. And it's nobody's fault. There's no manual for this.
So we made one.
We grabbed Puff Story, our Chief Revenue Officer, and Guy Wilcox, our Head of Product, to pick their brilliant brains. Two people who've scoped a lot of apps between them. We asked them to give it to us straight about what scoping actually looks like in 2026. What trips people up. What a genuinely good brief looks like.
Here's everything they said. Minus the the more colourful language (if you know our Puff, you know!).
So what does "scoping an app" actually mean? 📱
Scoping is the bit where you figure out what you're building, for whom, and why, before anyone writes a line of code.
Sounds obvious. Isn't.
)
A proper scope answers:
What specific problem are we solving?
Who are the users, and what do they actually need to do?
What does success look like, and how will we measure it?
What integrations, data, and tech constraints are in play?
What's in scope, and more importantly, what's out?
Skip this, and you're building on quicksand. Guy puts it better than we could:
"The sharp point of any bit of software is that it solves the right problem."
Guy Wilcox, Head of Product
Get the problem wrong, and it doesn't matter how clean the design is or how fast the engineers move. You're just building the wrong thing, faster.
The two mistakes (almost) everyone makes 🤔
1. Skipping straight to solutions
Most people arrive with features, not a problem. They've pictured the app, named the buttons, maybe even sketched wireframes. What they haven't done is checked whether any of it maps to what users actually need.
"They don't know whether those features are going to be well received, validated by users, or if it's even the right solution to the problem."
Guy Wilcox, Head of Product
2. Wanting all of it. Now.
Scope creep before the project's even started. Puff calls this one out: clients arrive with a million things and the urge is to nod along. But the best digital products do one thing brilliantly. Day one is not the day to jam pack in everything including the kitchen sink.
Your friendly neighbourhood app developers top tip: Start with a problem statement. Just one sentence. Sharp enough to zero in right on the pain point. Then build from there (sounds easy peasy, right?!).
How we actually scope an app project (the D&D way)
)
We run a process we call D&D, short for Discovery & Definition. No dragons, no twenty-sided dice, or 2 week campaign with your merry party o’ nerds. Just a series of collaborative exercises that happen before a single pixel gets designed.
Here's what's in the kit:
Problem statements
Every stakeholder gets a say on what the actual problem is. Not the solution. The problem. We refine it down to one agreed sentence that becomes the north star for everything that follows.
Vision alignment
This one surprises people. A lot of teams don't actually share a view of what success looks like. Different stakeholders are quietly pulling in different directions and nobody's noticed. We surface those tensions early. Better an awkward whiteboard moment now than an awkward demo six months in.
Personas and user journeys
Who's actually using this thing? What are they doing in the rest of their life when they pick it up?
Guy gave us a great example: when scoping a parental discount app, the team didn't just think about in-app behaviour. They thought about the daily reality of a new parent. Buying nappies at 2am, tracking what fits this week, sharing shopping lists with a sleep-deprived partner.
"That context shapes functionality in ways a feature list never could." Guy Wilcox, Head of Product
Golden path and event storming
For simpler flows, we map the golden path, which is the ideal route a user takes to get the thing done.
For complex platforms with a lot of behind-the-scenes logic, we use event storming, which defines rules, commands, and system behaviours before development starts. It sounds dry. It saves months.
Tech and integration mapping
What does this need to talk to? Are the Application Programming Interfaces (APIs) documented? What's the database model? What are the constraints?
Get these answered before you estimate, or your estimate isn't really an estimate. It's a vibe. Puff's waxes lyrical about the whole process with this short ‘n sweet steer: "You get out what you put in."
How long does scoping actually take? ⏱
Honest answer: depends.
Better answer: scoping isn't admin that happens before the real work. It is the real work. Or at least the thing that decides whether the real work is pointed in the right direction.
A light-touch scoping exercise that gets you to a confident ballpark? Days.
A full Discovery & Definition for a complex platform with multiple user types and integrations? Several weeks.
Either way, time in scoping isn't overhead. It's de-risking. Every hour spent properly defining the problem is potentially saving you weeks of rework later. Pay now or pay later, and "later" is always more expensive.
What we need before we can give you a real number 💸
A lot of people expect a detailed cost breakdown from a 30-minute intro call. We get it. We also can't do it. Here's why.
To give you a number we'd actually stand behind, we need to understand:
The complexity: how many features, and how they interact
The user types: how many distinct ones, and what each needs to do
The tech stack and constraints: existing systems? Platform restrictions?
The integration landscape: APIs documented? Do we have access?
The existing workflow: if this is replacing something, what does that look like?
Without these, any number we give you is a guess dressed up in a spreadsheet.
We can hand over a rough ballpark fairly quickly if we have a rough sense of the above. A detailed, defensible estimate takes meaningful time from a team of people, and that has a cost.
Puff, being Puff, doesn't sugarcoat it:
"To get to a cost, it takes a significant amount of time and money. If you want a detailed cost estimate, we need all the details. And if you don't have the details, you're not going to get that very easily." Puff Story, Chief Revenue Officer
What a properly good brief looks like 📋
In theory, a great brief includes:
A clear problem statement
A defined north star (what success looks like)
Documented personas and user needs
Measures of success
An overview of any existing solution or workflow
Tech stack, integrations, and documented APIs
A requirements document a developer can read and respond to
In practice? Guy's been in this industry 20+ years and can count perfectly complete briefs on one hand. Puff couldn't name a single one.
What agencies usually get is a feature list, a vague objective, and a lot of enthusiasm. That's not a dig, it's reality. The strategic thinking hasn't happened yet because most clients don't know they need to do it and don't have a framework for it.
That's exactly why our scoping process exists. It's designed to do that thinking with you, not assume it arrives pre-packaged in a Notion doc.
When scoping goes wrong: a (anonymous) horror story 👻
Names withheld to protect the identity of the scope gone sideways.
A client came to us with a platform that needed to pull data from a third-party information management system. The early assumption, documented but loosely, was that we'd get both read and write access.
Halfway through the build, that assumption collapsed. Write access wasn't available. The client pivoted: they'd build their own database on their end.
What followed was months of building on a foundation that was being poured at the same time we were standing on it. Every change on their side broke the sync on ours.
Guy's verdict:
"You're building on quicksand."
The hard won lesson is that tech integration assumptions need to be stress-tested and agreed before development starts. Ideally before the contract is signed. An Assumptions and Risks document isn't bureaucracy. It's the thing that stops six-figure surprises from landing in month four.
How AI has (and hasn't) changed scoping 🤖
This is where where scoping is at in the year of our Lord, 2026. And where we want to be honest rather than be AI jazz hands enthusiasts..
AI tools can genuinely speed up parts of the process: drafting problem statements from stakeholder inputs, surfacing patterns across user research, suggesting north star frameworks. Guy's been building internal tooling that walks teams through problem statements, personas, and journeys with AI assistance baked in. It's good.
But here's what AI hasn't changed, and arguably has made worse: the strategic thinking still has to happen. Skipping it just got more dangerous, not less.
"AI is making this so much harder because you can pump out software much quicker and cheaper, to validate and test concepts. But people don't really understand that that might not carry you through. There are security considerations, data considerations." Puff Story, Chief Revenue Officer
Shipping fast and cheap has never been easier. Shipping the right thing still takes the work.
Where to start (if you're starting from scratch) ✅
If you're reading this thinking "we haven't really done most of this", you're in damn good company. Most people haven't! This guide isn't here to make you feel behind; it's here to give you a shape for what good looks like.
Start with these four:
Write a problem statement. Not what you want to build. What problem you're solving, for whom, and why it matters. One sentence.
Define what success looks like. Not "the app goes live." What does it look like when it's actually working? What are the measurable outcomes?
Map your users. Who are they, and what do they actually need to do, in real life, not just in the app?
List your assumptions. Especially around tech and integrations. These are the landmines.
And if you're specifically thinking about scoping AI into your workflows or team - rather than a full product build - we've got something for that too. Our AI Adoption Toolkit is a practical, pick-and-mix playbook built for teams who want to bring AI in responsibly, without the chaos. It walks you through everything from picking the right pilot to putting guardrails in place that people will actually follow.
If you're not sure where to go from there, that's exactly what a good discovery process is for.
We've scoped apps for organisations working in humanitarian response, parental support, financial inclusion, and a long list of other places where getting it right really matters. The problems are always different. The work of defining them properly is always the same.
If you've got an idea and you want to talk through where to start, we'd love to have that conversation!
Let's talk about scoping your project →
Published on 13 April 2026, last updated on 13 April 2026