In short
An MVP can accept deliberate shortcuts in scale, automation, configurability, and non-core polish when they speed learning and are cheap to reverse. It should not accept debt that risks user harm, security, data integrity, permissions, recovery, measurement, or the team's ability to change the core workflow. Record every shortcut, trigger, owner, and repayment option.
Use consequence and reversibility
Evaluate a shortcut on two axes:
- What happens if it fails or remains?
- How expensive is it to change after real data and users accumulate?
Low-consequence, reversible shortcuts can be sensible. High-consequence or deeply embedded ones are not “moving fast”; they are transferring risk to users and the next team.
Debt often acceptable early
- manual internal fulfilment;
- one audience and one workflow;
- limited configuration;
- basic administration using safe internal tools;
- modest scale with measured limits;
- duplicated low-risk code pending a real pattern;
- fewer integrations or platforms;
- simple visual polish outside the core path.
Debt usually unacceptable
- weak authentication or authorization;
- exposing sensitive data;
- corruptible or unrecoverable records;
- no backups or recovery path;
- invisible production failures;
- inaccessible core journeys;
- no measurement of the hypothesis;
- undocumented credentials or deployment;
- code nobody can safely change;
- legal or contractual obligations ignored.
Create a debt register
Record:
| Field | Purpose |
|---|---|
| Shortcut | What was intentionally deferred |
| Reason | Evidence or time gained |
| Consequence | Failure or maintenance risk |
| Trigger | Usage, revenue, data, date, or feature condition |
| Options | Repay, replace, contain, or accept |
| Owner | Person watching the trigger |
Do not create a graveyard of vague cleanup tickets. Debt needs a decision boundary.
Architecture for learning
Avoid both extremes: a disposable tangle and a platform for millions of users who may never arrive.
Design the core entities and boundaries clearly, use mature services, keep deployment repeatable, instrument failures, and isolate the assumptions most likely to change.
Repay when evidence changes the economics
Triggers may include:
- usage reaches measured limits;
- manual work becomes a material operating cost;
- a second audience or workflow arrives;
- security or contract needs increase;
- repeated defects occur in the same boundary;
- development slows because every change touches the shortcut;
- fundraising, acquisition, or audit requires stronger evidence.
Common questions
Is all MVP code disposable?
No. Treat it as production when real users, data, money, or operations depend on it. Replace parts only when evidence justifies the cost.
Should an MVP have automated tests?
Automate the core business rules and risky regressions where tests provide fast confidence. Add coverage as behaviour stabilises and consequence grows.
Can manual work be technical debt?
It can be deliberate product debt rather than code debt. It is useful while volume is low and learning is high, provided cost, quality, and limits are measured.
When should debt be repaid?
When a defined trigger is reached or the debt materially increases risk, operating cost, or the time required to learn and change.
Who owns technical debt decisions?
Engineering explains consequence and options; product and business owners help decide priority against value and risk. One accountable owner watches the trigger.
