Before product-market fit, technical debt is acceptable when the shortcut is deliberate, bounded, and worth the learning it enables, without weakening obligations you have already accepted. Debt becomes dangerous when nobody understands the consequences, the repayment trigger, or the customer promise it puts at risk.
The choice is rarely between perfect engineering and reckless speed. A founder might reasonably postpone a sophisticated reporting interface while refusing to postpone correct access controls. Both decisions can support fast learning. The important work is deciding where simplicity ends and an unowned hazard begins.
Separate a shortcut from an unknown
A deliberate shortcut has a known limitation. You can explain why you chose it and what would make you change it. An unknown is something you have not evaluated. Calling both technical debt makes the second one sound more controlled than it is.
Martin Fowler's technical debt quadrant distinguishes prudent and reckless decisions, as well as deliberate and inadvertent debt. That vocabulary helps make the trade-off more precise. Read Fowler's original explanation.
Our suggested test is simple: can you describe the limitation to another person without vague language? 'We manually approve the first ten accounts, and stop new signups if the queue exceeds our daily capacity' is explicit. 'The backend needs some cleanup later' tells nobody what risk is being accepted.
You will still discover problems you could not foresee. A useful register makes those discoveries visible rather than treating them as evidence that planning was pointless.
Prefer shortcuts that preserve options
A reversible decision is easier to tolerate when the product is still changing. A plain interface, manual onboarding, a limited set of supported inputs, or a scheduled batch process may all be reasonable early choices.
Be more cautious where errors cross important boundaries. Access to another customer's information, destructive changes, ambiguous payment outcomes, and lost records can create consequences that a later refactor does not undo.
The OWASP Application Security Verification Standard provides a structured basis for examining application security requirements. See OWASP ASVS. The point is not that every prototype needs the same review. It is that 'we are early' does not explain away a responsibility the product has already accepted.
Reduce exposure when you cannot yet meet the responsibility. Use appropriate test data, fewer invited users, read-only access, or a narrower workflow. Scope is often the cheapest form of risk reduction.
A hypothetical example: manual imports
Imagine a founder tests a tool for small design studios. The product needs project data, but building integrations with every project management service would delay the pilot.
The founder accepts a simple spreadsheet import and manually reviews the mapping. They document the accepted format, who performs the review, and the maximum workload they can handle. They preserve the original file so that a mapping error can be understood and corrected.
This is deliberate debt if it enables useful learning and has an operating boundary. It becomes a problem if sales promises immediate imports from arbitrary systems while the founder silently spends each night repairing them.
The repayment trigger might be repeated demand for the same source or a sustained import queue that consumes the time needed for customer learning. That trigger is more helpful than promising to rewrite everything after product-market fit, a milestone that may remain ambiguous for months.
Keep a register that changes decisions
Use one row per meaningful shortcut. Record the decision, the reason, the affected workflow, the worst plausible consequence, the current workaround, and the trigger for review. Name an owner even if that owner is you.
Do not register every untidy variable. A long list of cosmetic improvements can hide the few decisions that matter. Prioritize by repeated cost, customer impact, and the difficulty of changing course.
Add the interest you actually observe. Does a shortcut add minutes to every onboarding? Does it cause repeated support questions? Does it make a small change risky? These are stronger reasons to address it than a general feeling that the code is embarrassing.
Sometimes the right decision is to leave debt in place. A rarely used internal view may not justify a rewrite if the limitation is understood and harmless. Repayment should compete with other useful work.
The failure mode: the permanent rewrite
A founder can spend months replacing an application whose demand is still uncertain. The new architecture may be cleaner while the customer problem remains unresolved.
Before approving a rewrite, name the current harm it will remove and the evidence that a smaller change cannot address it. If the explanation is mainly that the code no longer reflects your taste, ask whether the timing serves the business.
The opposite failure is treating every repeated problem as temporary. If the same workaround consumes each week's learning capacity, it is already shaping the company. Postponing it has a cost even if customers have not complained.
Your debt decision checklist
For the next shortcut, answer:
- What specific learning does this help us reach sooner?
- What limitation are we deliberately accepting?
- Which customer promise could be affected?
- Can we reduce scope instead of weakening that promise?
- What manual work will the shortcut create?
- What observable event triggers review or repayment?
- What is the smallest change that removes the costly part?
Keep the answer short and revisit it after actual use. Good early engineering protects the ability to learn and change. It does not require pretending that either speed or cleanliness is the only objective.