How we scope a mobile app project

Most failed mobile app projects can be traced back to decisions made (or avoided) in the first two weeks. Not the architecture choices. Not the framework decisions. The conversations that don\'t happen.

This is the rough script we use during our Discovery phase. It runs over 4–6 meetings, each about 60–90 minutes. By the end of it, we have a Product Requirements Document, a written assumptions log, a development plan, and — most importantly — a shared understanding of what we\'re actually building.

Week one: who is this for, really?

The first conversation is rarely about the app. It\'s about the people who will use it. The founder always has an idea of who their user is. Sometimes that idea is grounded in research, conversations, or operating experience. Sometimes it\'s a projection of who the founder hopes they are.

Our job in the first meeting is to surface the difference. The questions we ask:

• Who specifically uses this? Walk me through a real person you have in mind.
• How do they solve this problem today? What do they do at 9am on a Tuesday when this problem comes up?
• What\'s the cheapest, simplest version of this that would still earn its keep?
• What would success look like in 90 days? In 12 months?
• What\'s the worst outcome you\'re trying to avoid?

If the answers are abstract — "small business owners," "everyone who has ever..." — that\'s a flag. Not a fatal one, but it tells us we need to do a small user research engagement before going further. Building an app for an audience you don\'t deeply understand is a slow-motion disaster.

Week one continued: the technical reality check

The second meeting is where we lay out tradeoffs. People come to us with strong opinions about technical choices — usually picked up from a Hacker News thread — without understanding what those choices cost long-term.

Most "framework decisions" are actually team-and-budget decisions wearing a costume.

Questions we ask here:

• iOS only, Android only, or both? In what order? (Most US-only B2B starts iOS; most B2C goes both.)
• What\'s your in-house technical capability? Will there be in-house engineers maintaining this, or are we the long-term team?
• Is there an existing web product? An API? A database? What\'s the shape of the backend?
• Are there any hard constraints — required integrations, specific security standards (HIPAA, SOC 2), App Store guidelines that matter for your category?

By the end of week one, we usually have enough to write the first draft of a Product Requirements Document. It lists the features, the user flows, the technical constraints, the open questions, and the assumptions. It\'s not final. It\'s a working document we iterate with the client over the next week.

Week two: the assumptions log

Every project carries assumptions that, if they turn out to be wrong, blow up the timeline or budget. Naming them out loud early is the single highest-leverage thing we do.

An example assumptions log entry:

"We assume the existing PostgreSQL database can be queried directly by the mobile app via the existing REST API. If we discover the API doesn\'t support the data shapes the app needs, we\'ll need 2–4 weeks of backend work, which is not in this scope or budget."

That entry is half a paragraph long. But it has prevented at least three projects from blowing up. When the assumption turns out wrong — and one or two always do — we have a written record of what was supposed to be true, what we\'re finding is actually true, and a basis for an honest conversation about what to do next.

Common assumptions we always document:

• API readiness — does the backend actually support what the app needs to do?
• Asset availability — does brand, copy, photography, video exist? Or do we need to budget for creating them?
• Decision-making — who has final sign-off on design and scope? How fast can they review?
• App Store readiness — has someone enrolled in Apple\'s Developer Program? Set up App Store Connect?
• Third-party services — what\'s budgeted for Firebase, Stripe, SendGrid, Sentry, RevenueCat? These add up fast.

Week two continued: the build plan

By the second half of week two, we have a Product Requirements Document, an assumptions log, and rough wireframes for the core flows. Now we draft a build plan.

Our standard approach is two-week sprints. Each sprint targets a vertical slice of the product — one or two complete user flows, end-to-end, including backend work, mobile UI, and basic testing. At the end of every sprint, we run a demo. The client sees real working software. Not a mockup. Not a hand-wave. Something they can pull on their phone.

We plan 6–8 sprints for a typical MVP. The first sprint always includes setting up CI/CD, crash reporting, analytics, and the core auth flow — boring infrastructure that pays for itself every sprint after.

What we explicitly do not do

A few decisions we deliberately defer:

• Pixel-perfect design before we start building. We design 1–2 sprints ahead of build. Designing everything upfront leads to throwing away work as we learn during implementation.
• "Comprehensive" feature lists. We aim for a minimum viable product, not a maximum theoretical one. Features we don\'t build in the MVP go on a "later" list — we re-evaluate after launch with real user feedback.
• Architecture decisions for problems we don\'t have yet. Will the app eventually need offline sync? Maybe. Build it when there\'s evidence users want it, not at the start when we\'re guessing.

The handoff at the end of discovery

By the end of week two, the client has:

• A Product Requirements Document, signed off by both sides
• A wireframe set covering the core flows
• An assumptions log we both agree to
• A sprint-by-sprint build plan with milestones
• A final quote and contract

And — crucially — a written list of what we agreed is not in scope. The "not in scope" list often does more work than the "in scope" list during the project. When new feature requests come up (and they always do), we can refer back: was this in the original scope? If not, here\'s the change order conversation.

---

If you\'re scoping a mobile app and want a sanity check on your plan, we\'re happy to talk. Get in touch.