what technical debt to look for before you acquire
the demo works and the financials check out. then you open the repo. here’s what to look for before you wire anything.
you checked the listing. the demo runs, the limitations are disclosed, the handoff notes make sense. now you’re deciding whether to actually buy it. this is the part most buyers skip, and the part that costs the most when they do.
a working demo and good financials don’t tell you what it costs to keep running. that’s in the code.
test coverage is the first thing to check, and the number itself is the wrong thing to look at. a codebase with 90% coverage that tests utility functions and ignores payment processing is less reliable than one with 40% that tests the revenue paths. ask which parts are tested. if payment code, auth, or the core product logic have no coverage at all, every release is a coin flip on the thing that earns the money.
deployment is the second thing. if the founder deploys by muscle memory, you’re buying a process that lives in one person’s head. one sick day, one departed contractor, and the ability to ship stops. ask: can anyone else deploy this without the founder on a call? is there a pipeline? has anyone besides the founder ever run it? if the answer to any of those is no, budget two to three weeks of engineering after close just to automate what should already be automated.
architecture tells you how fast you can move after you own it. a codebase with clean separation lets you change a feature in a handful of files. one with tight coupling can mean touching fifteen or thirty files for the same change. ask the founder to describe a recent feature they shipped. how many files did it touch? if they can’t describe the architecture clearly, or if the honest answer is “it’s all kind of interconnected,” that’s not humility. that’s a warning.
dependency age compounds quietly. a codebase running a framework two major versions behind isn’t just outdated. it’s a rewrite getting closer every month. every outdated dependency makes the next upgrade harder, and the one after that harder still. ask the founder when dependencies were last upgraded. if it’s been over a year, ask what’s blocking it. “we haven’t had time” is the most honest answer and the most expensive one.
a seller who discloses technical debt early is a better seller to buy from.
documentation is where handoff cost lives. if the codebase is entirely in the founder’s head, with no readme, no architecture notes, no deployment runbook a new engineer could follow, you’re buying a product that will degrade the moment they leave. ask for the readme. ask for deploy instructions. if they don’t exist, budget four to eight weeks of overlap with the founder to reverse-engineer and write down what you bought.
none of this means a codebase has to be perfect. every product has debt. the question is whether the debt is known, mapped, and priced into the deal, or whether you’re discovering it after the money moves.
a seller who discloses technical debt early is a better seller to buy from. a buyer who checks for it is a better buyer to be.
written by solstead team