Shipping an MVP without shipping technical debt

"Move fast, we will clean it up later" is usually the moment a product acquires the debt it never pays off. But the opposite instinct, building a platform before you have a user, is just a slower way to fail. The useful question is not how much quality to skip. It is which parts of quality are cheap now and expensive later.

What is expensive to add later

Some decisions harden as soon as you have real users and real data. We treat these as non-negotiable even in a six-week build:

• The data model. Renaming a concept once it is spread across a schema, an API and a UI costs days. Getting the nouns right on day one costs an afternoon of argument.
• Authentication and permissions. Retrofitting multi-tenancy or per-record access into a system that assumed one flat user list is a rewrite, not a refactor.
• Migrations. From the first commit, schema changes belong in versioned migrations. It never gets easier to introduce that habit.
• Deployment. If shipping is manual, you ship less often, and every release carries more change and more risk.
• An audit trail. Recording who changed what is trivial to add early and close to impossible to reconstruct after the fact.

What is genuinely fine to defer

Equally, plenty of engineering effort is wasted before product-market fit:

• Microservices. A well-structured monolith will outlive most startups.
• Caching layers for traffic you do not have yet.
• Custom design systems. Use a sensible component library and spend the design budget on the two screens that matter.
• Exhaustive unit tests of code that exists to be thrown away. Test the money paths, the data integrity rules, and the parts with real logic.
• Admin interfaces you can get free from the framework.

Scope by outcome, not by feature list

A feature list grows by accretion because nobody can argue against any single item. An outcome makes the trade-off explicit: "a new customer can complete onboarding in under three minutes" tells you what to build and, more usefully, what not to.

We write the first release as three or four outcomes, then cut everything that does not serve one. The list of cut items is kept and shown to stakeholders, which turns "you forgot X" into "we deferred X, here is why".

Instrument from day one

An MVP is an experiment, and an experiment you cannot measure has failed by definition. Before launch we want error tracking, structured logs with request ids, a handful of product events for the core flow, and an uptime check. That is an hour of work and it is the difference between "users seem to drop off" and "72% abandon on the document upload step".

Write the handover as you go

If the system can only be run by the people who built it, it is not finished.

A README that covers local setup, environment variables, deployment and the three most likely failures is worth more than any architecture diagram. Written at the end it is a chore that gets skipped. Written as you go it is just notes.

The test that matters

Six weeks after launch, can a new engineer join, set the project up locally, ship a small change to production, and understand what broke if something does? If yes, you moved fast and did not take on debt. If no, the speed was borrowed.