What features should an MVP include?

Only features that validate your core value proposition. If a feature doesn't directly help users complete the primary task your product solves, cut it. Most successful MVPs launch with 3 to 5 core features: auth, the core workflow, and basic analytics.

Can I really build an MVP in 12 weeks?

Yes, if scope holds. We ship MVPs in 12 weeks at fixed price. The pattern: weeks 1 to 2 for diagnosis and design, weeks 3 to 10 for build, weeks 11 to 12 for launch hardening. Adding a sixth must-have feature mid-build is the single fastest way to break the timeline.

What's the smallest MVP scope you've shipped?

A two-feature web app for a Dublin operator: a booking form and an admin view. 5 weeks, $22K, took its first paying customer in week 6. Small isn't a weakness when the two features are the actual value. Tiny scope only fails when the product is missing the core workflow.

What gets cut first when the budget tightens?

Admin tooling (use a database GUI for 90 days), advanced analytics (use Google Analytics + a daily SQL email), custom roles (one admin role + one user role), and any AI feature that isn't the core value. Auth, payments, and the primary workflow can't move. Everything else is negotiable.

Should I include AI in v1?

Only if AI is the product. If your value prop is 'AI does X for you', yes, plan 4 to 6 weeks for it and budget for prompt iteration. If AI is a 'nice to have' on a CRUD product, push it to phase 2. AI features without product-market fit on the underlying workflow are the most common reason MVPs ship late and over budget.

When is a no-code MVP enough?

When the goal is to validate demand, not deliver the product. Bubble, Softr, or Airtable + a form is enough if you're testing whether users will pay for the idea. It's not enough once you need custom workflows, real performance, multi-tenant security, or integrations beyond Zapier. We've seen no-code MVPs survive to 200 users and break at 500.

How long should MVP development take?

6 to 12 weeks is the sweet spot. Under 6 weeks usually means the scope is too narrow to validate anything meaningful. Over 12 weeks means you're probably building too much before testing with real users.

MVP Scope Builder

Half of MVPs ship 6 months late and 60% over budget. This builder forces the scope decision now, before sprint 4 turns into sprint 14.

5 minute build
No signup
Anchored to real shipped-MVP data

Step 1 of 714%

Authentication & Users

Pick what you need. 6 options · 0 selected

Tap a row to add it. Then tap the priority chip to set it as must-have, nice-to-have, or future.

Email / Password LoginStandard signup and login flow
0.5w
Social Login (Google, GitHub)OAuth integration for 1-click signup
0.5w
SSO / SAMLEnterprise single sign-on
1.5w
Roles & PermissionsRole-based access control
1w
User ProfilesProfile pages with avatar, settings
0.5w
Team / Org ManagementInvite members, manage teams
1.5w

Direct answer

MVP scope is the smallest set of features that proves your product works for real users without breaking the budget. Most working MVPs ship with 3 to 5 features in 8 to 12 weeks for $30K to $80K. Phasing matters because every feature added to v1 pushes launch by 1 to 6 weeks and risks shipping a product nobody validated.

01 The math behind the builder

How a feature becomes a number of weeks

Every feature you tick has an effort weight baked in, calibrated on real shipped-project data. The builder adds them up, then phases them. Here's what the weights actually look like.

1 week

User profile

Auth, email confirm, password reset, basic profile fields. Library work, not invention. Same shape on every project.

2 weeks

Stripe payment

Checkout, webhooks, refunds, receipts. Fixed-scope when you stick to one currency and one product type. Adds a week per extra payment provider.

3 weeks

Admin dashboard

CRUD on your core tables, role-based access, an audit log, CSV export. Skipping this in v1 sounds clever and bites by week 6.

4 weeks

AI content generation

Prompt design, model selection, output guardrails, cost caps, a feedback loop. Most of the time goes to the guardrails, not the model call.

5 weeks

Real-time chat or notifications

Sockets, presence, delivery state, push to web and mobile. The infra is straightforward. Edge cases (delivery, retry, offline) eat the rest.

6 weeks

Marketplace search and matching

Faceted search, ranking logic, two-sided onboarding, trust scoring. This is the feature most founders underestimate by a factor of two.

Two engineers in parallel cuts the timeline roughly in half on independent features. It doesn't help on tightly coupled work like auth, payments, or the core workflow, where coordination cost eats the gain.

02 The scoping decision

When phasing beats shipping it all at once

Phasing isn't always right. Both approaches work. The choice depends on cash, certainty, and what 'launch' means for your brand.

Phase it

Phasing wins when

You're cash-constrained and need revenue or a funded milestone before phase 2.
Requirements are uncertain and you want real-user feedback before committing the rest of the budget.
You have multiple bets to test (B2B vs B2C, two pricing models, two verticals) and need data to pick one.
The team is new to the problem space and needs to ship to learn what users actually do.

Ship it whole

Monolithic wins when

Scope is locked by contract, a regulator, or a launch partner. Partial scope isn't legal.
You have 9 to 12 months of runway and the brand depends on a polished, complete launch.
You're entering a regulated space (health, finance, payments) where a half-built product creates liability.
The product is a replacement for an existing tool the team uses every day, so day-1 parity matters.

Worth saying out loud

MVP doesn't mean buggy. It doesn't mean slow. It doesn't mean designless.

MVP means minimum scope, not minimum quality. We've watched too many founders ship literal beta-grade software, lose the audience they spent 12 months earning, and never recover the trust. Three working features that feel finished beats ten features that feel broken. If you can't make a feature feel done, cut it from v1.

03 What you actually need

MVP, prototype, POC: which one matches your goal?

The three get used interchangeably and they shouldn't. The wrong choice burns a quarter and signals nothing useful.

TypePurposeUsersCost & time

POCProve a single risky thing works at all.Your team and a couple of friendly testers.$5K to $15K, 2 to 4 weeks.

PrototypeValidate a flow with real users before writing production code.10 to 30 design-partner users in a test environment.$10K to $30K, 3 to 6 weeks.

MVPShip a small, real product that can take payment and survive use.Your first paying customers or pilot accounts.$30K to $80K, 8 to 12 weeks.

If you're early and risk lives in one assumption (people will pay, this AI is accurate enough, integration X is possible), build a POC. If you're testing a flow, build a prototype. If you're going to market, build an MVP.

Methodology

Estimates are based on MVP projects RaftLabs has shipped, most of them in 12 weeks at fixed price. Weights are recalibrated when our actual delivery rates shift. The builder errs on the cautious side: when a feature could be 4 or 6 weeks depending on scope, it picks 6 because over-delivering on time is cheaper than missing a launch date.

Work with us

Where to go from here

Useful next steps

More on MVP development

Work with us

Prototype to Production Services

See the service

Article

How to Build a Company Review Platform Like Glassdoor: Cost, Features, and What Actually Ships

Building a company review platform like Glassdoor costs $50,000-$80,000 for a vertical MVP or $80,000-$140,000 for a full platform. This guide covers who builds these, what phases cost, and where most projects fail.

Want a second pair of eyes on your phased plan?

Send your scope. We tell you what we'd cut, what we'd keep, and where we've seen this pattern break in similar builds. Free, 30 minutes, no pitch.

Related tools

Common questions

: Only features that validate your core value proposition. If a feature doesn't directly help users complete the primary task your product solves, cut it. Most successful MVPs launch with 3 to 5 core features: auth, the core workflow, and basic analytics.
: A web-based MVP typically costs $30K to $80K depending on complexity. Simple MVPs (landing page + waitlist + core feature) ship for under $30K. Complex MVPs with AI features, payments, and integrations range from $60K to $100K+.
: Yes, if scope holds. We ship MVPs in 12 weeks at fixed price. The pattern: weeks 1 to 2 for diagnosis and design, weeks 3 to 10 for build, weeks 11 to 12 for launch hardening. Adding a sixth must-have feature mid-build is the single fastest way to break the timeline.
: A two-feature web app for a Dublin operator: a booking form and an admin view. 5 weeks, $22K, took its first paying customer in week 6. Small isn't a weakness when the two features are the actual value. Tiny scope only fails when the product is missing the core workflow.
: Admin tooling (use a database GUI for 90 days), advanced analytics (use Google Analytics + a daily SQL email), custom roles (one admin role + one user role), and any AI feature that isn't the core value. Auth, payments, and the primary workflow can't move. Everything else is negotiable.
: Only if AI is the product. If your value prop is 'AI does X for you', yes, plan 4 to 6 weeks for it and budget for prompt iteration. If AI is a 'nice to have' on a CRUD product, push it to phase 2. AI features without product-market fit on the underlying workflow are the most common reason MVPs ship late and over budget.
: When the goal is to validate demand, not deliver the product. Bubble, Softr, or Airtable + a form is enough if you're testing whether users will pay for the idea. It's not enough once you need custom workflows, real performance, multi-tenant security, or integrations beyond Zapier. We've seen no-code MVPs survive to 200 users and break at 500.
: 6 to 12 weeks is the sweet spot. Under 6 weeks usually means the scope is too narrow to validate anything meaningful. Over 12 weeks means you're probably building too much before testing with real users.