Technical debt
The future cost of shortcuts taken now, such as a simpler approach that works today but will need reworking as the product grows.
Updated October 2026 · with examples from our own builds
What does technical debt mean in practice?
Every product carries technical debt. Some is deliberate: a simpler method shipped because the data is small, with the better one planned for later. Some is accidental: code written in a hurry that nobody now understands. Like financial debt it isn't wrong in itself; unrecorded debt is the problem.
The question worth asking isn't 'is there debt?' but 'is it written down, and what triggers paying it off?' A shortcut with a named limit, such as 'fine until the list grows past this', is a decision. A shortcut nobody remembers is a surprise.
Debt compounds when features are built on top of it, so paying it down before a big new feature is often cheaper than afterwards.
Technical debt at a glance
- Deliberate debt
- Recorded, with a trigger for repaying it
- Dangerous debt
- Unrecorded shortcuts other features build on
- Repay before
- Building major features on top
Where has technical debt come up in our builds?
Moving trainer coordinates into MongoDB's geospatial format needs a backfill across five models, so while the trainer list is small enough to score in memory we shipped haversine and wrote down the next step: a GeoJSON point beside each location, a 2dsphere index and $geoNear.
Within a migration job, objects copy one at a time in key order. That was a deliberate v1 trade-off, because it makes the checkpoint trivially correct.
When each industry pack got its own stack, we named the trade-off: a fix that applies to every industry now costs one edit per industry, in return for packs that evolve independently and can't leak into each other.
Common questions about technical debt
How much technical debt is acceptable?
As much as is written down with a reason and a trigger, and no more. Recorded debt with a planned repayment is a sound decision; debt nobody knows about is a risk.
Should we pause features to pay off technical debt?
Pay it off when the next feature depends on the part carrying it, or when it keeps causing bugs. Otherwise schedule it alongside feature work rather than stopping everything.
Related terms
Sources
Planning a product and not sure where technical debt fits? Ask us, or browse all 116 terms in the glossary.