Product

Surviving past the MVP: what to make durable now and what can wait

Abstract cover art for the article: Surviving past the MVP: what to make durable now and what can wait

A product survives past its MVP when the team knows which parts were experiments and which parts are foundations, and treats them differently. Experiments can stay rough and disposable. Foundations, meaning your data model, your delivery pipeline, your design tokens and the few interaction patterns everything else copies, need to be made durable early, because they get more expensive to change every month you build on them. The evidence for this is better than most startup advice: Google’s DORA delivery research, controlled studies of design systems and longitudinal work on technical debt all point the same way.

The prototype that got promoted

An MVP exists to answer a question. Eric Ries called the output of that work validated learning, which the Lean Startup site describes as “a rigorous method for demonstrating progress” under extreme uncertainty. The deliverable of an MVP is the answer. The code is a byproduct.

Trouble starts when the byproduct ships. The demo worked, a design partner signed, the board wants a launch date, and the prototype becomes version 1.0 by default. Nobody decided that the hard-coded pricing logic, the one-off modal styles or the schema sketched in an afternoon were fit to carry paying customers. They just stayed.

You can usually tell which situation you are in by asking what the MVP was supposed to prove. If the team can name the hypothesis, the metric and the result, you ran an experiment and you have learning to build on. If the honest answer is “people liked the demo,” you have a prototype with users. That may still be a valuable asset. It has not earned the right to become your architecture.

What the delivery research says

DORA is the long-running software delivery research program at Google Cloud. Its most repeated finding is that speed and stability move together. The program’s own guide states that speed and stability are not tradeoffs and that the two sets of metrics are correlated for most teams. Teams that ship often also tend to break less.

DORA now tracks five metrics. Three describe throughput: change lead time, deployment frequency and failed deployment recovery time. Two describe instability: change fail rate and deployment rework rate. If you measure nothing else after launch, measure these. They tell you whether the product is getting easier or harder to change, which is the question that matters once the MVP has done its job.

What AI-assisted development changed

The 2024 report looked closely at AI’s effect on delivery, and the result was uncomfortable. According to Google’s announcement of the 2024 DORA report, a 25% increase in AI adoption was associated with an estimated 7.5% increase in documentation quality, 3.4% in code quality and 3.1% in code review speed. Yet as adoption increased, the researchers estimated a 1.5% decrease in delivery throughput and a 7.2% reduction in delivery stability. Individuals got better at their tasks. The system shipped less reliably. The authors pointed back to basics such as small batch sizes and solid testing.

The 2025 report, retitled the State of AI-assisted Software Development, surveyed nearly 5,000 technology professionals. By then 90% of respondents said they used AI at work, and more than 80% believed it had raised their productivity. The link to throughput had turned positive. The link to instability had not. In a follow-up analysis on dora.dev, DORA’s researchers describe higher AI adoption as associated with increases in both throughput and instability, with time saved during generation often spent again on auditing and verifying output. The report’s framing is that AI amplifies whatever system it lands in, good or bad.

For a post-MVP team, the practical reading is simple. AI tools make it cheap to produce a prototype and cheap to keep extending it. They do nothing on their own to make it safe to change. If your MVP was generated quickly and shipped without tests, a deploy pipeline or a settled data model, AI will help you stack more onto it faster, and the DORA data gives you no reason to expect your change failures to stay flat.

Design systems: the measured gains and their limits

A design system is shared infrastructure for interface work, the way a deploy pipeline is for code. It makes each change cheaper by removing decisions that have already been made. The published evidence is thinner than the enthusiasm, so it is worth reading closely.

In 2019, Figma’s data science team ran an experiment in which designers completed one task with a design system and one without, alternating the order. With the system, they finished 34% faster. Figma itself frames that as the ceiling, because the system in the test was current and directly relevant to the task.

On the engineering side, Sparkbox had eight of its developers build the same contact form twice from a Figma file, once from scratch and once with IBM’s Carbon components. Median build time fell from 4.2 hours to 2 hours, which Sparkbox reports as 47% faster. The top two submissions for visual consistency used the design system. Accessibility results were mixed, and two developers’ hand-coded versions beat their Carbon versions. The authors call it a small study, and it is.

Two things follow. The gains are real but conditional on a system that is maintained and matches the work in front of the team. And neither study measured a young company building its first system, which costs time before it saves any. For a team of four shipping one product, a full component library with a documentation site is premature. Design tokens for color, type, spacing and radius, plus a handful of core components, are a different matter. They take days to set up, and they are the part that hurts most to retrofit once dozens of screens carry their own hard-coded values.

Technical debt and UX debt compound

Technical debt has one of the better longitudinal studies in software research. Besker, Martini and Bosch, writing in the Journal of Systems and Software in 2019, surveyed 43 developers over time and ran 16 interviews. Developers wasted on average 23% of their development time because of technical debt. The most common extra activity was additional testing. The authors also found that developers were frequently forced to introduce new debt because of debt that already existed. That second finding is the compounding effect founders tend to underestimate.

UX debt behaves the same way and is easier to ignore, because it rarely breaks a build. Nielsen Norman Group defines it by analogy with tech debt: the cost of shipping the faster or easier solution instead of the right one. Three date pickers. Onboarding copy that describes a feature you cut. A settings page that follows none of the patterns the rest of the app uses. Each one is small. Together they make the product feel unreliable, and they raise the cost of every new feature because designers have no settled pattern to extend. NN/g’s advice is to log UX debt in the backlog with a severity rating, then pay some down every sprint or schedule dedicated cleanup sprints.

Taking on debt to learn faster is the whole point of an MVP. The damage comes from debt nobody recorded, sitting in parts of the system nobody decided were temporary.

How to decide what to make durable now

A workable test has two parts. Ask how hard a decision is to undo, and how much else will be built on top of it. High on both means make it durable now. Low on both means leave it rough and move on. Mixed cases get a written note and a date to revisit.

Area Make durable now Can wait
Data model Core entities, their names and relationships, who owns each record Reporting tables, admin views
Delivery pipeline Automated deploys, tests on the paths that take money or data, a way to roll back Full test coverage, load testing
Design foundations Tokens, type scale, core form and navigation components Full component library, documentation site
Auth, billing, permissions A proven provider and a role model you can extend Custom flows, rare plan types
Feature surfaces Only what customers use every day Most of them, until usage data says otherwise

Add one rule on top. Anything you choose to leave rough gets written down with the reason and the trigger that would change your mind, such as the tenth enterprise customer or a second product line. That list is the difference between debt you chose and debt you discover during an outage.

When this advice does not apply

Some teams should ignore most of this. If you have no evidence yet that anyone wants the product, durability is waste. Find the demand, then build properly. If the MVP was disposable by design, say a concierge service, a clickable prototype or a no-code build, there is nothing to harden, and the right move is a planned rebuild with the learning in hand.

Regulated products sit at the other end. In health, finance or anything that handles sensitive personal data, security, access control and audit trails belong in the “now” column from the first commit, whatever stage you are at. And if you are a single engineer, a formal design system is overhead. A shared tokens file and some discipline will carry you a long way.

A next step for this week

Book ninety minutes with whoever leads product, design and engineering. List the ten parts of the product that the most other parts depend on, and label each one experiment, foundation or unknown. Then pull last quarter’s change lead time and change fail rate, even if you have to count deploys by hand. Anything labeled experiment or unknown that sits where changes fail most often is your first hardening work. The rest can stay rough until the numbers say otherwise.

Sources