Technical debt gets discussed as though all of it is bad. It isn't. Shipping something imperfect to find out whether anyone wants it is a good trade. The skill is knowing which shortcuts charge interest and which don't.

Debt that's genuinely free

Ugly code in a place you never touch. If it works and nothing needs to change there, its ugliness costs nothing.

Doing it manually. Adding users by hand for the first fifty, editing a config file to change a price. Not scalable, entirely fine at small scale, and it means you don't build an admin panel for a product that may not survive.

Hardcoded values. Fine until there are two of them.

No tests on stable code. Tests pay off where code changes.

Debt that compounds

Data in the wrong shape. This is the expensive one. Every day of collection makes it harder to change, and unlike code you can't just rewrite it.

Missing error handling. Every silent failure is a future debugging session with no information.

Duplicated logic. Every copy is a place a fix needs applying, and the one you forget is the bug.

Anything security-related. These don't degrade gracefully; they're fine right up until they're an incident.

No way to know it's broken. Without logging or monitoring, every problem takes ten times as long.

The question to ask

Not "is this good code?" but "what does this cost me when I come back?"

debt-audit.txt
Here's my project: <paste or describe>

List the shortcuts and rough edges. For each:
- What does it cost me if I never touch this code again?
- What does it cost me if I need to change it in three months?
- Does it get worse over time on its own, or stay the same?

Then rank: what to fix now, what to fix when I next touch that area,
and what to deliberately leave alone forever.

That last category should have things in it. A list where everything needs fixing isn't a prioritisation.

Write the shortcuts down as you take them. Debt you remember taking is manageable; debt you rediscover in a panic is not.