How many features should an MVP include?

Think in journeys, not counts. One complete critical path—onboarding to core value—often implies several small features, but they should all serve the same user and the same learning goal. If you cannot name that goal in one sentence, you probably have multiple MVPs disguised as one.

Should an MVP include payments and billing?

Include them if proving willingness to pay or cash flow is part of your riskiest assumption. If you are testing engagement first, manual invoicing or a single payment link may suffice. Never treat money movement as an afterthought when real customer funds are involved—use production-grade patterns appropriate to your jurisdiction and volume.

How long should MVP development take?

Calendar depends on domain, integrations, and team fit—not a universal week count. Healthy engagements time-box discovery, lock MVP scope in writing, and aim for demoable increments every one to two weeks so drift is visible early. If no one can ship a thin slice in that rhythm, scope or team shape is usually wrong.

What is the difference between MVP and prototype?

A prototype persuades insiders; an MVP survives contact with real users in a production-like environment. Prototypes can omit persistence, security, and ops. MVPs carry enough quality and observability that you can learn from behavior, not just interviews.

Who should own MVP scope on the client side?

One product owner with authority to say no—or yes with a trade-off—beats a committee. Committees slow decisions; slow decisions burn calendar without reducing risk. Name a single accountable owner and a small stakeholder map for escalation.

Guide

How to Scope an MVP That Actually Ships (Without Betting the Roadmap)

An MVP that ships is one complete user journey—thin, end-to-end, on real infrastructure—that proves or disproves your riskiest assumption; everything else stays in the backlog until that loop works.

Most MVPs fail before code ships because the scope quietly becomes "the whole product." Founders add must-haves, stakeholders add parity features, and engineering inherits a six-month wish list dressed up as a sprint. The fix is not more discipline slogans—it is a concrete scoping contract: one actor, one job-to-be-done, one measurable outcome, and a definition of done that a user can exercise without you in the room. Below we walk through how to cut scope without cutting learning, how to write a brief your agency or team can estimate honestly, and how to tell when you are smuggling a v2 into v1. Baaz has shipped MVPs and platform slices for startups and enterprises since 2018; this is the framing we use when a client says "we need everything" and still has twelve weeks of runway.

What an MVP is for (and what it is not)

An MVP exists to reduce uncertainty cheaply. You are buying evidence: will someone complete a workflow, pay, return, or invite a teammate? If the build does not target one falsifiable claim, you have a prototype for morale, not a product for learning.

An MVP is not a stripped-down version of your five-year vision. It is the smallest release that still teaches you something your spreadsheet cannot. That difference matters when someone argues for "just one more" integration.

Nor is MVP an excuse for unsafe software. You still ship with auth, backups, and basic observability appropriate to real users—especially if money or personal data moves. "Minimum" refers to scope, not negligence.

Start with the riskiest assumption, not the feature list

List the beliefs that must be true for the business to work: pricing, channel, workflow fit, technical feasibility, regulatory path. Circle the one that hurts most if it is wrong. Shape the MVP to test that assumption first.

If your risk is "Will enterprises connect their IdP?" the MVP includes SSO and a boring admin shell—not a polished marketing site. If the risk is "Will users finish onboarding?" the MVP is onboarding plus one core action, not reporting dashboards.

When every assumption feels equally critical, you are avoiding prioritisation. Force rank: one primary, two secondary. Secondaries wait behind the first working loop.

The thin vertical slice (the pattern that actually ships)

Pick one persona and one job: "A billing admin connects Stripe and sees the first paid invoice in our UI." Trace the path end-to-end: sign-up, permissioning, integration, happy-path UI, failure states that block money, and enough logging to debug.

Horizontal slices—"build all the APIs first"—often stall because nothing is demonstrable until late. Vertical slices surface integration and UX surprises early, when dates still flex.

Define "done" as something you can demo to a stranger: they click, they see state change, they could use it tomorrow without engineering babysitting. If your definition of done is "code merged," scope is still fuzzy.

How to cut scope without losing the story

Use the backlog as a parking lot, not a negotiation arena. Every new ask gets a card and a phase label—MVP, post-MVP, or unknown—before it touches the sprint. Visibility reduces stealth scope.

Replace "no" with "phase two with metric." Example: "Search across all entities" becomes "phase two after we see how users navigate with filters on the primary entity." Ties cuts to learning, not opinion.

Kill duplicate paths: two ways to accomplish the same outcome doubles test matrices and support load. Pick the simpler path for v1; add elegance when retention proves the workflow.

Automate last. Manual ops behind the curtain—CSV uploads, admin toggles, concierge onboarding—are legitimate for early MVPs when they shorten calendar and clarify what to automate later.

The one-page brief your partner can bid fairly

Send the same brief to every finalist: actor, job-to-be-done, success metric, must-have integrations, compliance constraints, environments you need, and target demo date. Uniform inputs produce comparable proposals.

Call out non-goals explicitly. "No mobile app in MVP" and "No multi-tenant white-label" prevent well-meaning teams from architecting for futures you have not funded.

Attach user flows as numbered steps, not mood boards alone. Engineers estimate steps and edge cases; pretty screens without flows invite optimism bias.

Integrations, compliance, and the hidden calendar eaters

Third-party sandboxes, OAuth review, and webhook reliability routinely consume weeks. If an integration is not on the critical path for your riskiest assumption, stub it or fake it with manual reconciliation until the core loop works.

Regulated data and SSO requirements are not "nice-to-haves" you can slip in before launch—they change architecture. Front-load legal and security review if your buyer cannot buy without them.

Signals you are smuggling a v2 into v1

You have more than three "must-have" personas. Personas multiply scope faster than features.

Every sprint adds "small" requests without removing something. That is scope creep with better manners.

No one can state the single metric that will decide whether MVP succeeded. If success is a vibe, the build will drift.

You are optimising for investor demos instead of user tasks. Deck-ready UX and learning-oriented UX overlap—but they are not the same brief.

After launch: read the loop, then widen

Ship, measure, fix the top friction in the loop, repeat. Widening to secondary personas and platforms comes after the primary loop stabilises—otherwise you multiply variables and learn slowly.

Keep a public or internal changelog habit early. It trains the organisation to treat scope as versioned, not infinite.

Explore Product Strategy, Custom Software, and AI Development. If a build has stalled, see software project rescue. When you are ready to talk, get in touch.