Business Ops: The Tech Debt Nobody's Refactoring

Why operations matter to investors in due diligence, and why you should care too.

Last week I was interviewing a partner at an investment fund about best practices for COOs and we hit upon something that I think needs a blogpost.

I am comparing notes and interviewing other operators about best practices to fill this knowledge base with the things they know. And when Thijs (Gitmans from SHIFT invest) and I talk we get inspired about this topic, and that's how we landed on this.

We went somewhere more interesting than best practices, to why operational hygiene matters enough for an investor to care about it before a term sheet is even close and why founders themselves should care about solving it.

This will come up in diligence — here's why investors care

Whether it is a messy shareholder agreement, an unsigned contract, an employment agreement that doesn't hold up — none of that is just about that document. An investor doing diligence isn't just grading your paperwork. Yes, they are checking whether the fundamentals are in place, whether you do own that IP, and whether there is anything blocking in your shareholder agreement. But more than that, they're using it as a proxy for some things they can't directly observe yet: whether you know outside of your own skills what it takes to run a business and whether you are coachable.

How broken things are tells its own story. A founder who lets the same mistake happen twice isn't unlucky — say, letting someone go without correctly locking down severance or vesting terms, the second time after already paying for that lesson once. They're showing they never understood why it mattered the first time. That's the real thing that an investor is scanning. It also shows why "I fixed it because the VC asked" and "I fixed it because I get it" show two very different founders, even when the paperwork looks identical on the page.

It's code

Maybe this is closer to the hearts of many founders: code. Buggy or messy code, just a temporary quick fix that stayed in forever. Every founder who's shipped software knows: at some point you stop and refactor parts. Skip that, and eventually the whole thing collapses on exactly the foundation you never had time for. In software, this exact failure mode has a name: tech debt.

I get why your contracts, your shareholder agreement, your IP registration aren't neat, clean, and structured on day one. Like you shouldn't start a new product by building out the microservice orchestration layer first — you ship something to end users, and you clean up the architecture once it's actually worth cleaning up. Bigger fish to fry, right? That's true — up to a point.

If you don't fix it, the problem shows up the moment you actually need it. As if you discover, mid-incident, that the code you need to debug is undocumented and nobody remembers how it works. In exactly the same way, you don't want to discover — at the one moment it actually matters — that the contract you need is missing, that you only have a version nobody signed, or that an old draft of an important clause quietly made it into the final one. At a genuinely critical moment, that is the kind of thing that sinks you.

It's debt — with a brutal interest rate

Tech debt works exactly like the name says: it's borrowed, not free, and it carries an interest rate. In our conversation Thijs and I landed on hiring as a better example than contracts to point out how comparable to (tech) debt this is.

A bad hire isn't a one-off cost — it's a loan, and the interest rate is brutal. Two bad hires, not five, not ten, just two, will keep you occupied almost full-time: managing around them, covering for them, eventually replacing them.

Add up the hours, and it has eaten all your capacity and you didn't build anything else big that quarter. Comparable to how the interestburden of a loan can eat the entire gross margin or EBITDA of a company or force cost reduction to be able to pay the interest.

Where to start

I hope this way of talking about business operations convinces some founders to fix some of their tech ops debt.

And remember that none of this asks for perfection. What it asks is whether you can tell the difference between fixing something because someone told you to, and fixing it because you understand why it's there. Check your shareholder agreement, your employment contracts, your IP registration — not for an investor, for yourself (Legal & Compliance).

And look honestly at your last two hires: investment, or loan?

PS Want to see where your own operational maturity stands, stage by stage? The diagnostic gives you a concrete picture. Or set up the virtual COO as a SKILL.md and start with a check in to help guide you through getting things in order.

Based on an interview of a partner at an impact-VC fund, September 2026. Part of an ongoing series on the Duct Tape to COO framework.

The diagnostic covers the same ground as this post — legal and hiring — calibrated to your stage.

Part of an ongoing series on the Duct Tape to COO operational maturity framework.