How to scope an MVP when building is cheap

An MVP is not a small version of your product. It's the smallest thing you can build that will prove or kill your riskiest assumption — and if you scope it any other way, you're just shipping a shorter list of guesses. This distinction matters more in 2026 than it did in 2020, because AI removed the cost barrier that used to enforce it. When building was expensive, scarcity did your prioritisation for you. Now it doesn't, and the discipline has to come from somewhere else.

Why this matters now

Building got dramatically cheaper. Learning did not.

• 42% of startups fail because there was no market need for what they built — still the single biggest cause in CB Insights' startup post-mortem analysis, and a share that has held remarkably steady across cohorts since 2019.
• 80% of features in the average software product are rarely or never used. That's from Pendo's 2019 Feature Adoption Report, which analysed 615 subscriptions from customers who had used the product for over a year. Pendo put a price on that unused surface area: roughly $29.5 billion in development spend across publicly traded cloud software companies.
• The Standish Group's CHAOS research reached the same conclusion two decades earlier — 50% of features are used almost never, 30% infrequently, and only 20% often. Two independent studies, twenty years apart, same answer.

Now set that against 2026: teams adopting AI assistants report spending more time debugging rather than less, with one survey this year putting it at 67%. Cheap generation raised the ceiling on how much you can build in a sprint. It did nothing for how much you can learn in one.

The mechanism: a feature is a liability, not an asset

Here's the part most scoping conversations get wrong. Teams treat features as assets — things you accumulate, that make the product worth more. In practice, most of a feature's cost lands after it ships:

• It has to be maintained, forever, against OS updates and dependency churn.
• It generates support load, edge cases, and bug reports.
• It's a surface where things break, and a surface an attacker can reach.
• It adds cognitive load for every user who doesn't want it, and for every engineer who has to reason around it.

Build cost is the down payment. Ownership is the mortgage. AI cut the down payment close to zero and left the mortgage exactly where it was — which is why "it's cheap to add" has quietly become the most expensive sentence in a planning meeting.

The question was never "can we build this?" It's "are we willing to own this for five years?" Cheap generation answers the first question and skips the second.

How to actually scope it

Scope by risk, not by feature list. Concretely:

1. Write down the assumption that kills you if it's wrong. Not five assumptions — the one. Usually it's behavioural: "people with this problem will change what they do today in order to use our thing." Sometimes it's technical: "this can run fast enough on-device." Name it in one sentence.
2. Find the cheapest honest test of that assumption. Honest means real users with real stakes — their time, their data, their money. A landing page tests curiosity, not retention. Match the test to the risk you actually have.
3. Cut everything that doesn't serve the test. Onboarding polish, settings screens, account systems, admin panels, the second platform. If removing it doesn't invalidate the test, it isn't in v1.
4. Set the kill criteria before you build. Decide now what result would make you stop. Teams that skip this step never stop — they just keep adding features to a product nobody asked for, because there's no defined moment at which they're allowed to admit it.
5. Ship it to real users sooner than feels comfortable. An MVP's entire value is the feedback loop. A polished MVP that lands in six months has learned less than a rough one that shipped in six weeks and iterated four times.

The one thing you must not cut: quality on the path you're testing. If your riskiest assumption is that people will log their meals every day, the logging flow has to be genuinely good. A slow, ugly logging screen produces a false negative — you'll conclude nobody wants the product when in fact nobody wanted that screen. Narrow scope, high quality inside the scope. That's the whole trick, and it's the part cheap tooling tempts you to invert.

Our opinion

Most "MVPs" we're asked to quote aren't MVPs at all — they're v1 of the full product with a smaller budget attached. They arrive with a settings screen, three user roles, and a notification system, and none of it tests anything. The team hasn't decided what they're trying to learn, so every feature feels equally necessary, because nothing has been given a job.

The reframe we'd argue for: an MVP is an experiment with a user interface. Experiments have a hypothesis and a stopping rule. If you can't say what result would make you walk away from the idea, you haven't scoped an MVP — you've started building the product and hoped.

The counter-intuitive part is that cheap AI-assisted building makes this discipline more valuable, not less. When every feature cost real money, the budget said no on your behalf. Now nothing says no except judgement. A partner who will tell you to cut half the brief is worth more in 2026 than one who will cheerfully build all of it and invoice you for the privilege.

How Ashvara helps

We scope MVPs around the thing you're actually trying to learn, then build that part properly. In practice that means a shorter feature list than most clients expect, and a higher bar on whatever survives the cut — because a narrow product that works beautifully teaches you something real, and a broad one that works adequately teaches you nothing.

We've shipped 29 apps to the App Store, most of them deliberately narrow, so we've had a lot of practice deciding what doesn't go in v1. That judgement is the core of our MVP development work, and it carries through to iOS app development when an MVP earns its next version. If you have a brief and you're not sure which half of it matters, tell us what you're trying to learn and we'll help you find the smallest build that answers it.

Related reading: what it costs to build an app in 2026 and pay-once, where it fits.

Sources: Pendo, "2019 Feature Adoption Report" — 615 subscriptions analysed (pendo.io); CB Insights startup post-mortem analysis; The Standish Group, CHAOS research.