MVP development: how to build a minimum viable product and what it costs

What an MVP is (and what it isn't)

A minimum viable product is the smallest thing you can put in front of real users to test your riskiest assumption. Usually that assumption is "people have this problem badly enough to change their behavior, or pay, to solve it." The MVP exists to produce evidence, not to impress investors with a feature list.

Here is what an MVP is not: a buggy, rushed version 1 of the full product. "Minimum" refers to scope, not quality. If the one thing your product does is slow, confusing, or crashes, users leave and you learn nothing, because you can't tell whether they rejected the idea or the execution.

A useful mental model: build a skateboard, not one wheel of a car. A skateboard is small, but it's a complete way to get from A to B. One wheel of a car is a fraction of something nobody can use yet.

Five types of MVP, from cheapest to most built

Not every MVP needs code. Pick the cheapest type that can honestly answer your question.

1. Landing page (smoke test)

A page describing the product with a sign-up, waitlist, or pre-order button, plus a small amount of paid or community traffic. It measures interest, not usage. Good for testing positioning and pricing before you write any product code.

2. Concierge MVP

You deliver the service by hand, openly. If your app will recommend meal plans, you write the meal plans yourself for ten customers over email. You learn exactly what people value, and you find out which steps are worth automating.

3. Wizard-of-Oz MVP

Users see what looks like a working product, but a human does the work behind the curtain. This is especially useful for AI products: test whether people want the output before you spend weeks tuning a model pipeline.

4. No-code MVP

Tools like Bubble, Glide, Softr, or Airtable plus Zapier can get a functional product live in days. Great for internal tools and simple marketplaces. The limits show up with custom UX, offline mobile use, realtime collaboration, performance, and anything that needs a native app store presence. Our comparison of custom vs off-the-shelf vs no-code goes deeper.

5. Single-feature software MVP

Real code, real product, one core workflow done well. This is what most people mean by "MVP development," and it's the right call when the value depends on the software itself: a mobile experience, realtime sync, an AI feature, or an integration no-code tools can't handle.

How to scope an MVP: one core job and a cut list

Scoping is where MVPs succeed or fail. Most budgets blow up not from hard engineering but from "while we're at it" features. Here's the process I use with founders:

1. Name one user. Not "small businesses". Something like "independent worship leaders who run slides on Sunday".
2. Name one core job. The single thing they hire your product to do. Write it as a verb phrase: "build a setlist and present it on the big screen".
3. Map the shortest path. List every screen and step from first open to job done. That path is your MVP.
4. Write the cut list. Everything else goes on a visible list of things you are deliberately not building yet: settings, admin dashboards, social features, multiple roles, dark mode, a second platform.
5. Pick one success metric before you write code, so you can't move the goalposts later.

Common items on a healthy cut list: password reset flows (use magic links or Sign in with Apple/Google), custom admin panels (use your database dashboard), payments (invoice manually at first), notifications beyond one essential type, and analytics beyond a handful of key events.

How much does an MVP cost?

Cost depends mostly on which type you build and how many screens, integrations, and user roles are in scope. The ranges below are estimates based on typical projects at a US-based studio like ours; your number will depend on your scope.

Budget for running costs too: hosting, database, and AI model usage are often small at MVP scale, but the Apple Developer Program is $99/year and a Google Play developer account is a $25 one-time fee. For a full breakdown by app type, see how much it costs to build an app.

If you want a number for your specific idea rather than a range, you can get a free app plan: answer a few questions and we'll send back a scoped plan with an estimate.

How long does an MVP take?

For a focused software MVP, plan on roughly 6–12 weeks from kickoff to real users. Here's a typical breakdown (estimates, not guarantees):

App store review adds some uncertainty for mobile: most reviews clear within a day or two, but a rejection can cost you several days. Launching a web version first sidesteps that. More detail in how long it takes to build an app.

Tech choices that don't paint you into a corner

The classic trap is "we'll build it cheap and rewrite later." Sometimes that's fine. Often the rewrite never gets funded, and you're stuck with a stack that fights you. You can move fast and keep options open:

• Start web-first when you can. A web app ships instantly, updates without store review, and works on every device. Add native apps once you know people come back. Our web app development work usually starts here.
• If you need mobile, use Expo (React Native). One TypeScript codebase for iOS and Android, over-the-air updates for quick fixes, and full access to native APIs when you need them. It's what we use for mobile app development, and it shares logic with a React web app.
• Use a managed realtime backend like Convex. You get a database, server functions, auth integration, and live sync without running servers. That cuts weeks off an MVP and still scales into a real product.
• Keep AI behind your own API. If you're adding AI features, call the model from your backend, not the client, so you can swap providers, control costs, and log outputs for evaluation.
• Own your data and code. Make sure the repo, the cloud accounts, and the app store listings are in your name from day one.

This is the same approach we used for Star, a setlist and presentation app: a tablet app plus a web app at app.starapp.io, built on the same React and TypeScript stack we use for client work.

Metrics to judge whether your MVP worked

Decide your metrics before launch, and favor behavior over opinions. "I'd totally use this" is not data. Useful signals:

• Activation: what share of sign-ups complete the core job at least once?
• Retention: do they come back in week 2 and week 4 without you nudging them? This is the strongest single signal.
• Willingness to pay: pre-orders, paid pilots, or deposits beat survey answers every time.
• Pull: are users asking for the next feature, referring others, or complaining when it breaks? Complaints are a good sign; indifference is the bad one.
• Time to value: how long from first open to first success? Shorter almost always wins.

Set a threshold for each in advance, such as "at least 30% of activated users return in week 2". The exact number depends on your category; what matters is that you commit to it before you see the data.

What happens after the MVP: iterate, pivot, or scale

An MVP ends with a decision. Roughly, the evidence will point you one of three ways:

• Iterate: people use it but drop off at a clear point. Fix that step, ship weekly, and re-measure. Most products live here for a while.
• Pivot: a different user, job, or feature shows the pull you hoped for. Keep what works and change the focus. Because you kept the MVP small, a pivot costs weeks, not months.
• Scale: retention holds and people pay. Now it's time to work through the cut list, add the second platform, harden infrastructure, and invest in onboarding and growth.

If the honest answer is "nobody cares", that's also a successful MVP. You found out for a fraction of the cost of a full build. If you're earlier than this and still shaping the idea, start with how to go from idea to app.

Common MVP mistakes

• Building for everyone. Two user types means two onboarding flows, two permission models, and half the learning for each.
• Shipping both platforms on day one when a web app or a single cross-platform build would answer the question.
• Skipping customer conversations because building feels more productive than listening.
• Treating the MVP as a throwaway and choosing tools you'd never scale on, then being forced to rebuild right when traction arrives.
• No analytics at launch, so you have users but no evidence.
• Waiting for perfect. If you're not slightly embarrassed by the scope (not the quality), you probably waited too long.
• Hiring on price alone. A cheap build that misses the core job wastes more money than a well-scoped one. Our MVP development engagements start with scoping for exactly this reason.

When you're ready, get a free app plan and we'll help you find the smallest version worth building.