How to Scope a Mobile MVP in 60 Minutes Flat

Most mobile MVPs are scoped by accumulation — the feature list grows in every founder-engineer conversation, and three weeks in, the build quietly contains three months of work nobody priced in. This article is how to scope a mobile MVP the opposite way: one sixty-minute sitting, five phases, three artefacts a senior engineer can actually quote against. It is the conversation I run with founders before I take a build, and the same shape I would want a founder to run on their own before they post a job ad or sign an agency SOW.

Why scope is the decision that runs every other decision

The most expensive mistake a non-technical founder makes is treating scope as a list of features. It is not. Scope is a constraint sheet: what is in v1, what is parked, what is out, and which four decisions you have already made so the engineer does not have to guess. Every decision downstream — framework, architecture, hiring shape, launch date, paywall model — inherits from scope.

The right time to scope is before the SOW, not after. Once you have signed, every renegotiation is a price negotiation; before you sign, every conversation is a clarity exercise. Knowing how to scope a mobile MVP before commissioning the build is what separates founders who launch on time from founders who spend six weeks renegotiating their feature list with their engineer. Note: this article assumes you have already decided you are building an MVP rather than a full product. If that decision is still open, see when to build MVP vs full product first — the scoping exercise only makes sense once you know which shape you are building.

I have watched founders walk into a week-1 kickoff with a 47-item feature list and walk out three weeks later having shipped none of them, because nobody made them pick the seven that mattered. I have also seen RoomFlash ship against a hard real-estate-event deadline with zero scope creep and App Store approval on first submission — same engineer time, same six-week window, opposite outcome. The difference was a sixty-minute conversation that happened before kickoff, not after it.

The 60-minute scoping framework: five phases, one output per phase

Here is the framework. Block sixty minutes, calendar invite, no other meetings. Open a single shared document. Walk the five phases in order. Each phase outputs exactly one artefact — when the phase ends, the artefact is on the page or the phase is not done. This is the mobile MVP scoping framework I use both for paid engagements and for the founders I talk to in a free intro call, and it is the most reliable answer I have to how to scope a mobile MVP in a way a non-technical founder can actually run.

Three rules: you do not write code in this hour, you do not negotiate price in this hour, every phase ends with one written artefact rather than a discussion summary. The output is documents your engineer can read, not a feeling of progress.

Phase 1 (10 min) — The one-sentence business question

Write the question your business is asking, in one sentence, in plain English. Not the product, not the feature list — the question. "Will couples pay seven dollars a month to share decision logs with an AI coach?" is a business question. "Build a couples app" is not.

The artefact is one sentence that fits on a sticky note. If you cannot write it in one sentence, you are not scoping yet — you are still figuring out what you are building. Stop the timer and resolve that before continuing.

Phase 2 (15 min) — The demo flow

Write the single user journey that, if it works on day one, answers the business question. Plain English, one page, no jargon. Start at "I just opened the app" and end at "the business question has an answer". This is the spine of how to scope a mobile MVP — every feature in the rest of the conversation either supports this flow or it does not.

The artefact is a numbered list, 7–15 steps. Each step is a screen and an action: open app → sign in with Apple → tap "log today" → answer three questions → see partner's last log → tap "ask coach". Resist side flows, resist settings. The demo flow is "the thing that proves the business question", not "the thing that ships".

Phase 3 (15 min) — The in / parked / out triage

Take every feature anyone has ever proposed for this app. Write each on a single line. Sort each into one of three columns: In (ships with v1, supports the demo flow), Parked (ships with v2, does not break the demo if missing), Out (not on this product within a year).

Most founders enter this phase with 30–50 candidates and exit with 7–12 In, 15–25 Parked, the rest Out. This is the phase the article exists for: what to cut from MVP scope is the question this triage answers, and the framework forces the answer to be written, not negotiated in the next meeting. If a feature wants to be in two columns, it goes Parked. The MVP feature prioritization framework is exactly this rule, run with discipline, on every candidate.

Phase 4 (15 min) — The four scope-as-architecture decisions

Four decisions look like features but are architecture in disguise. They determine the shape of the build, and they are brutally expensive to change in week four. Make them now, in this hour:

1. Auth shape — anonymous, email/password, Sign in with Apple, social? Pick one for v1.
2. Payment model — free, one-time, subscription, freemium? Pick one for v1.
3. Analytics taxonomy presence — events named upfront (yes) or added later (no)? Pick one for v1.
4. Real-time — does the demo flow require live sync (chat, presence, multiplayer)? Yes or no for v1.

These belong in this hour because whether they are in v1 at all is a scope question. Whether the answer is Firebase Auth or Supabase Auth is an architecture question — and that one lives in the non-technical founder's guide to mobile app architecture. Phase 4 closes the loop on how to scope a mobile MVP by surfacing the four decisions every founder forgets to make during feature triage.

The artefact is four lines, four answers.

Phase 5 (5 min) — The constraint sheet

Write the constraints. Hard launch date, budget ceiling, device classes (just iPhone, iPhone + Android, with or without iPad), languages, regulated jurisdictions if any. If you do not know an answer, the constraint is not real yet — write "TBD" and resolve it in the next 48 hours.

The artefact is a constraint sheet that lives next to the demo flow and the triage list. With these three documents, you can scope mobile app before build kickoff in a single conversation rather than a three-week back-and-forth — and the same bundle lets you compare engineer quotes apples-to-apples instead of guessing why one number is twice the other.

The four scope decisions that are actually architecture decisions in disguise

Phase 4 deserves a section of its own because it is the most-skipped step. Founders treat auth, payments, analytics, and real-time as "the engineer will handle it". They will not — each of these decisions changes the build's shape in week one. Skip them and you spend week four rebuilding the data layer because nobody named "chat" until the Friday kickoff and the sync model was wrong.

You are not deciding how in Phase 4. You are deciding whether. Whether v1 is subscription or free is a scope decision because subscription pulls in StoreKit / Play Billing wiring, a paywall provider, a restore-purchase path, and a sandbox loop — none of which exist in a free app. Whether real-time is in v1 is a scope decision because real-time pulls in a different state model, backend shape, and testing surface.

Boyfi shipped in six weeks with dual subscriptions running in parallel and two AI providers behind a single abstraction because those four answers were written down in the scope conversation, not discovered in week three.

What founders typically over-scope (and the cuts that always survive scrutiny)

Patterns I see repeatedly when cleaning up a scope:

• Settings screens. Granular notification toggles, theme switches, data-export options — before there is a single user. Park.
• Profile customisation. Avatars, bios, themes. None of these answer the business question. Park.
• Admin tooling. A founder needs to moderate or send pushes. Park to v2; in v1, you do that work from a console you ship in two days, not a polished admin panel.
• Multiple paywall variants. A/B testing paywalls makes sense above ~1,000 users a week. Park until the traffic makes the test statistically honest.
• Onboarding flows longer than three screens. Each extra screen typically drops a chunk of users before activation. Cut.
• Multi-language at launch. Pick one language. Add the rest after you have validated the business question in one market.

The cuts that survive scrutiny are the ones where the founder, after a week of trying to defend them, admits they are not on the path to answering the business question. Park them, do not delete them — parking buys you the optionality to ship them later when the business question has answered yes.

I have cleaned up codebases where the founder added "oh, and chat" on a Friday kickoff; six months later the data layer was structurally wrong for real-time and the whole sync model had to be rebuilt. The triage is what prevents that. The same discipline is what made MyCoach survive sixty-plus updates over two years with the coach-client scope unchanged — the scope conversation up front decided the spine, and everything else shipped on top.

What a good 60-minute scope looks like in practice — and what to do next

By minute 60, you have three pages: a one-sentence business question, a 7–15 step demo flow, a three-column triage with the four architecture-style decisions answered, and a constraint sheet. This is the input bundle a senior engineer needs to quote and to start week one against. The next conversation you have is "here is the scope sheet — what is missing, and what would you change?" — not "what should we build?".

Two more things to know. AI tooling can turn a one-sentence idea into a fifty-item user-story doc in seconds. It cannot tell you which of the fifty your business actually needs in 90 days. The cutting is judgement, not generation. And agencies often quote against your first feature list because it produces a bigger invoice; a senior engineer's first move on a real engagement is to halve the scope before quoting. The sixty-minute exercise is what lets you run that filter yourself before you talk to anyone.

If you want to run the build against the scope you produce, the chronological playbook is how to build a mobile MVP for your startup, the categorical architecture treatment is the non-technical founder's guide to mobile app architecture, and the night-before binary list is the mobile MVP launch checklist for founders. Scope is the input to all three. Once your three artefacts exist, the natural next question is how much does it cost to build an app that matches them — a worked example, priced feature by feature shows what a scope sheet like yours looks like once you run it through the tiers.

If you want a second pair of eyes on a scope before you commission the build, that is what an intro scoping call is — sixty minutes, scope before SOW, the same shape as this exercise. Tell me about your project if your In column still has more than seven items and you want a structured cut before you sign anything. Knowing how to scope a mobile MVP is the single most useful skill a non-technical founder builds before commissioning a build — the framework above is the exercise, and the three artefacts on the page are the proof you ran it.