MVP vs. Launch V1: How to Scope a Focused First Version of Your iOS and Android App

"MVP" is one of the most misused phrases in product. Founders use it to mean "the smallest version I can launch." Lean Startup originally meant "the smallest experiment I can run to test a hypothesis." These two definitions sound similar and are very different.

The first one ships into the App Store and gets reviewed by users. The second one might never leave a TestFlight build. Confusing them is how you end up paying $80k for a public launch of something that was supposed to be a private experiment.

Here's how we scope a focused first version that's actually worth launching — and how we tell our clients which of the two they actually want.

The definitions, sharper

An MVP, in the original Lean Startup sense, is a learning instrument. You ship it to 50 people. It might be ugly. It might not be in the App Store at all — it might be a TestFlight link, or even a Figma prototype. The point is to test a hypothesis as cheaply as possible.

A launch v1 is the smallest version of a product you can charge for, or hand to a real user without embarrassment. It has to do its core job well. It has to be stable on real devices. It has to be in the App Store and discoverable. It's not a prototype — it's a product.

Most of the time, founders who ask for an "MVP" actually want a launch v1. They don't want a $25k experiment; they want a $60k product. Calling it an MVP just gives them permission to keep the budget low. But the budget doesn't change what the App Store will reject.

How to tell which one you actually need

Three questions clarify it:

1. Will real users find and download this without anyone telling them to? If yes, it's a launch v1. If no, it might be an MVP.
2. Do you need to put it in the App Store? If yes, launch v1. If no — TestFlight or Play Internal Testing distribution is fine — it can be an MVP.
3. Will you be embarrassed if a user posts a screenshot? If yes, you wanted a launch v1.

The honest answer to those three for most founders is launch v1, launch v1, launch v1. Plan and budget accordingly.

If you want a clean breakout of what your launch v1 should and shouldn't include, start with a two-week discovery. We deliver a prioritized feature list and a fixed quote against it.

The scoping pattern that works

For a launch v1, every feature lands in exactly one of three buckets:

v1: required to do the core job. Without this feature, the app doesn't solve the user's problem. Auth, the primary flow end-to-end, persistence, error handling, and the one thing your app is actually for.

v1.5: required for a happy launch. Polish features. Email confirmations, profile editing, password reset, push notifications, basic analytics, share-to-social. These don't change what the app does. They make it not feel broken.

v2: nice-to-haves and "wouldn't it be cool if". Everything else. Be ruthless here. A v1 with 8 well-built features beats a v1 with 20 half-built features, every time.

The mistake we see weekly is founders insisting that a feature is v1 because "the app makes no sense without it." Most of the time, the app makes plenty of sense without it. It just makes less sense to the founder, who has been living with the product in their head for a year.

The "one thing" test

We run our clients through a short exercise during discovery. We ask them: in one sentence, what does your app do? Then we make them say it in one sentence without compound clauses.

If the answer is "the app connects climbers with partners at their gym," v1 is the gym-partner matching flow, end-to-end, plus auth, plus a thin profile. Everything else is v1.5 or v2.

If the answer is "the app connects climbers with partners at their gym, and tracks their climbs, and lets them post photos, and has a community feed, and...", that's not one sentence. That's four sentences. Pick one and ship it. The others come back in v1.5 once you have real users telling you which they actually use.

A real example: My Home Delivery

When we scoped My Home Delivery — a React Native marketplace for big-and-bulky on-demand delivery — the founder's original feature list had 22 items. The "one sentence" was: customers book a furniture pickup, drivers accept it and complete it, payment clears automatically.

That sentence has exactly three roles (customer, driver, payment) and three flows (book, accept/deliver, pay). v1 contained:

• Customer: sign-up, browse delivery types, schedule a pickup, pay, track the driver
• Driver: sign-up, see jobs, accept, mark complete
• Payment: Stripe Connect multi-party
• One admin dashboard for the founder to monitor

That's it. Twelve features in v1. Ten in v1.5 (rating system, dispute flow, in-app chat, repeat-booking shortcut). The remaining items went to v2 or were cut entirely.

Build time was 14 weeks. The app shipped without a single feature anyone could call superfluous. Six months later, three of the v1.5 items had been added based on actual usage data — and three of them had been cut because users never asked for them. The discipline at scoping time paid back many times over.

Anti-patterns to watch for

The "platform" trap. Founders building marketplaces or social products often want all sides of the platform shipped at once. Customer-facing app, driver-facing app, vendor portal, admin tool. v1 is usually two of those, not four. The other two can be served by a manual workflow you'll automate later.

The "feature parity" trap. "If we don't have feature X, users will pick a competitor." Sometimes true. Most of the time, users pick based on the one thing they care about, not the long-tail feature list. Don't ship a worse product to compete on count.

The "I'll know what to cut later" trap. You won't. The thing you're sure is necessary at scoping time will still feel necessary at week 8. The cuts have to happen now, on paper, before any code is written. Otherwise they become re-quotes and timeline slips.

The "we'll polish later" trap. Polish is not a feature you add at the end. Polish is a constraint that lives across every feature. You either build something polished or you build something that needs to be rebuilt before launch. Decide now.

What v1.5 buys you

The reason scoping a tight v1 works is that v1.5 follows almost immediately. Most of our clients ship v1 at week 16 and v1.5 at week 20. Real users in the product for those four weeks tell you which v1.5 features to prioritize and which to drop. That information is worth more than the same four weeks spent building everything you thought you needed in v1.

This is also why founders who run their own v1 scoping tend to over-stuff it. They're imagining themselves as the user, and they would use everything. Real users use a smaller subset, and they tell you which one only after they've used the product.

The shortcut

If this scoping work feels overwhelming — and for most non-product founders it should — that's exactly what discovery is for. Two weeks, $4k–$10k, you walk out with a v1, v1.5, and v2 list and a fixed quote against v1.

Talk to us about a discovery engagement and we'll scope your first version against the reality of your users, your budget, and what you can actually ship in 16 weeks. You'd rather find out what to cut now than at week 10 of the build.