Mobile-first MVPs: a fixed-price playbook

Most mobile MVPs go wrong in the same place: scope. The founder has an idea, a deck, and a budget. The shop quotes T&M because “the scope isn’t fully defined yet.” Six months and three sprint extensions later, the app ships at twice the original budget and half the original scope. The founder learns that “T&M startup MVP” is a phrase that translates to “best-effort and we’ll see.”

A fixed-price mobile MVP is shippable in 12 weeks if — and only if — the scope is disciplined enough to underwrite a fixed-price commitment. This post is the playbook.

The 12-week shape

A defendable 12-week mobile MVP has this shape:

Weeks	Phase	Output
1	Scope lock	Written feature spec, screen-level wireframes, technical architecture
2	Design + scaffold	Design system, navigation skeleton, infrastructure baseline
3–8	Core feature build	The 4–6 features that define the MVP, shipped end-to-end
9	Polish + edge cases	Empty states, error handling, accessibility, loading states
10	Beta + feedback	Closed-beta with 20–50 users; structured feedback collection
11	Iteration on beta feedback	Fix-list from beta, applied within scope
12	Launch + handover	Store submission, launch communications, handover documentation

The 12 weeks fit when scope is 4–6 core features, plus design system, plus auth, plus the standard scaffolding. They don’t fit when scope is “everything we might want eventually.”

What the scope lock produces

The scope-lock week is what makes the rest of the engagement work. The output is a written artefact with:

1. Feature list. 4–6 core features. Each described in 1–2 paragraphs. No “we’ll figure out the details.”
2. Screen-level wireframes. Every screen, even simple ones. Annotated with what the user can do on each.
3. Data model. Entities, relationships, the major API endpoints. Sketched, not finalised, but specific enough to start building against.
4. Tech stack decisions. React Native or Swift/Kotlin? Backend in what language? Hosted where? What auth provider? These decisions don’t change mid-build.
5. What’s out of scope. Explicit list of features explicitly deferred to v1.1. The discipline of writing this list often saves the engagement.

If week 1 produces less than this, the engagement should pause until it does. Ten days of scope discipline saves 10 weeks of scope confusion.

The 4–6 core features

A defendable MVP’s feature scope is small. Anything more than 6 core features is not an MVP; it is a v1.

Examples of “core feature” granularity:

• Authentication + onboarding flow.
• The primary user-facing workflow (e.g., “post a job,” “book a session,” “track an order”).
• The primary monetisation surface (subscription, transaction, in-app purchase).
• A basic notification system (push + email).
• An admin / settings surface.
• A minimal social or sharing element if the product depends on it.

Six features at this granularity are about right for 12 weeks. Eight is probably too many. Four might be too few — the product can’t stand on its own.

What we ship

For mobile MVP clients in our Build line, the deliverable includes:

• The mobile app (iOS + Android via React Native, or native if scope requires).
• The backend API (typically TypeScript/Node or Python, hosted on the client’s cloud).
• Auth + identity infrastructure (typically Auth0, Clerk, or Cognito).
• Push notification infrastructure.
• Basic admin web app for managing the data the mobile app reads/writes.
• Analytics integration (PostHog or whatever the client prefers).
• Crash reporting (Sentry or equivalent).
• CI/CD for app store submission (Fastlane or EAS).
• Documentation for ongoing development by client team.

All code in the client’s GitHub from day one. Infrastructure on the client’s cloud. Store accounts owned by the client.

What changes after launch

A mobile MVP at week 12 is not a finished product. It is a credible v1 with the user-facing surface to start collecting real-user feedback. The next 12 weeks (often a v1.1 engagement) typically involve:

• Iterating on actual usage data (the planned product is rarely the same as the validated product).
• Adding the 2–4 features deferred from MVP scope.
• Performance and stability tuning at real user volumes.
• Optimising the conversion funnel (onboarding, activation, retention).

We scope v1.1 as a separate fixed-price engagement, with scope informed by the data the MVP collected.

Where the playbook breaks

Two cases:

1. The product is genuinely complex. Some products (heavily regulated, hardware-integrated, multi-sided marketplaces with critical mass requirements) cannot be shipped as 12-week MVPs. The Build engagement is longer, and the scope is correspondingly larger. We say so when we see it.
2. The founder cannot commit to scope. If the founder keeps adding features during weeks 2–8, the engagement degrades into T&M-by-other-means. We have a strict change-order process for this; founders who can’t work within it should pick a different vendor.

For most B2C and B2B mobile MVPs at typical complexity, the 12-week fixed-price playbook ships a credible product. The discipline is the differentiator.

---

Read more: /build/mobile-bundle · /build/ · /method/