riccardo@pisano:~$ cd ~
~/due-diligence

Technical due diligence, from the seller's side

Most guidance on technical diligence is written for the buyer. I have been on the seller's side of a completed acquisition of a company I wrote the code for. I get founders ready for the review before a sale or a raise, so it confirms the story instead of unravelling it.

4× founder 1 exit · June 2025 bootstrapped · zero funding remote worldwide
See the track record

Why diligence catches founders out

By the time a buyer's technical team shows up, the deal is supposed to be mostly agreed. What that team finds can still move the price, add earn-out conditions, or end the process. The problem is timing. Most of what diligence penalises, a business that lives in one person's head, an architecture nobody wrote down, security work that got deferred for two years, cannot be fixed in the few weeks between a letter of intent and the review.

I have been on the other end of this. I coded one of the first LinkedIn outreach platforms myself, grew it to 500+ B2B clients with zero outside funding, built a team of 20, and sold the company in June 2025. It took two years and three signed deals, mostly because my financials were not ready, which I went through in detail on the Practical Founders podcast. So I prepare founders for the questions I was actually asked, not a generic checklist.

What a buyer's technical review looks at

Every acquirer and lead investor runs some version of this. The specifics vary; the categories do not.

›Founder-dependency. Can the company run, ship, and recover from an outage without you? This is the single finding buyers weight most, and the hardest to fix late.
›Code and architecture. Is it maintainable, is it documented, and do the big decisions have a reason behind them, or just history?
›Security and compliance. Handling of secrets and customer data, access control, and whatever regime applies to your market, before it becomes a deal condition.
›Technical debt and scalability. What will need rebuilding soon, what it will cost, and whether the system holds up at the buyer's scale.
›IP and licensing. Who owns the code, whether contractors assigned their work, and whether any open-source or vendor terms create a liability.
›Team and process. Who does what, how work ships, and what breaks the day a key engineer leaves.

The readiness checklist

This is the list I work through with founders, in the order a buyer's review runs, hardest to fix first. The test for each line is whether you can answer it with a document or a demo instead of a sentence.

Founder-dependency

›A written runbook for every recurring thing only you do, including the ones you do without noticing.
›One deploy, one outage recovery and one customer escalation handled end to end by somebody who is not you, with the date it happened.
›Admin access to every system in at least two people's names.
›An honest answer to what breaks in the first month if you stop working, rather than the confident one.

Code and architecture

›A README that gets a new engineer to a running local environment in under an hour, tested on somebody who has never seen the repo.
›A short written reason behind each decision a reviewer will ask about, the database, the framework, the hosting, anything unusual.
›Dead code and abandoned experiments deleted, or marked as dead.
›An architecture diagram that matches what is actually deployed.

Security and compliance

›Every secret out of the codebase and out of the commit history, in a secret manager, rotated.
›A list of who has access to production and to customer data, with the leavers removed.
›One page on how you handle data, what you collect, where it lives, how long you keep it, who else sees it.
›Whatever regime applies to your market checked before a buyer raises it. A gap you find is a task. The same gap found by them is a deal condition.

Technical debt and scalability

›A written list of what you would rebuild and what it would cost in weeks, in your own numbers.
›The load the system has actually handled, measured rather than estimated.
›The three things that break first at ten times the volume, named.

IP and licensing

›A signed assignment from every contractor and every employee who has touched the code, including the ones from five years ago.
›A dependency licence report, with anything copyleft identified and a decision recorded next to it.
›Confirmation that nothing runs on a personal account, a personal domain or a personal API key.

Team and process

›Who does what, written down, including the parts that live in one person's head.
›How work gets from an idea to production, in one page.
›What happens the day each key engineer leaves, per person.

I sold my own bootstrapped SaaS in 2025, so this is the list I ran on myself rather than a template. In a $295 monthly session we work out which of these six you are weakest on and what to fix first, and the first 30-minute discovery call is free.

How I get you ready

The work is not cosmetic. It is making the findings true and boring before a stranger goes looking for them. I help founders reduce founder-dependency, clean up the technical story, and turn the messy parts into a documented list rather than a surprise, so the buyer's reviewer finds exactly what you told them they would.

Concretely, an honest audit of where the technical story is weak; a plan to reduce the bus factor and write down the architecture; the obvious security and IP gaps closed; and a data room that answers the predictable questions before they are asked. When the review comes, it becomes a formality instead of a negotiation you are losing.

This is one strand of fractional CTO work. If you are not selling yet but want the option open, the same preparation is just good technical hygiene, and it is far cheaper to build in than to retrofit under a deadline.

When to start

Earlier than feels necessary. Six to eighteen months before you expect to sell or raise is enough time to move founder-dependency and documentation, the two things that cannot be crammed. If you are already in a process, a focused review still pays for itself by finding the issues before the buyer's team does, while you still control how they are framed.

Questions founders ask

What is technical due diligence?

Technical due diligence is the review a buyer or investor runs on your technology before they close a deal. They look at whether the code is maintainable, whether the business can run without any one person, what the security and compliance exposure is, how much technical debt is hiding in the roadmap, and who actually owns the code and the third-party dependencies. The output is a risk assessment that moves the price, changes the deal terms, or kills the deal. Preparing for it in advance is what keeps it from doing the last one.

How do I prepare my startup for technical due diligence?

You reduce founder-dependency so the company is not one person's head, you write down the architecture and the decisions behind it, you close the obvious security and compliance gaps, you make the licensing and IP ownership clean, and you turn the messy parts into a known, documented list rather than a surprise. The goal is that a buyer's technical reviewer finds what you already told them they would find. I sold my own bootstrapped SaaS in 2025, so I prepare founders for the questions I was actually asked, not a generic checklist.

When should I start preparing for technical due diligence?

Before you have a term sheet, ideally six to eighteen months before you expect to sell or raise. Most of what diligence penalises, founder-dependency, undocumented architecture, deferred security work, cannot be fixed in the few weeks between signing a letter of intent and the review. Starting early turns diligence from a scramble into a formality. If you are already in a process, it is still worth a focused review to find the issues before the buyer's team does.

Do I need a lawyer or a technical advisor to get ready for due diligence?

Usually both, because they check different things. Your lawyer reviews contracts, corporate records and IP assignments. The buyer's technical reviewer opens the code, the infrastructure and the team, and asks whether the company runs without you. A lawyer can confirm your contractors signed their IP assignments, and cannot tell you whether the code they wrote will survive the review. I prepare the technical half.

Why hire a fractional CTO for due diligence instead of a consultancy?

Because a consultancy sends you a checklist and a junior team; a fractional CTO who has sold a company sends you the person who has been in the room. I have been on the seller's side of a completed acquisition of a company I wrote the code for myself, so I know which findings actually move a deal and which ones a buyer raises to negotiate. You get one senior operator, a small number of founders at a time, and no agency markup.

What does due diligence readiness cost?

It usually starts with one session a month at $295, one focused hour on where your technical story is weak and what to fix first, written up in your Workroom. Deeper readiness work runs as sessions every other week or every week, $545 or $995 a month, or a fractional CTO engagement at Miami cost, scoped per company, typically a few days a month. The first 30-minute discovery call is free, and it is where we decide which of those fits. See full pricing.

~/contact

Thinking about a sale or a raise?

Tell me where you are and roughly when. The first 30 minutes are free, and you will leave with an honest read on how your technical story holds up.

Miami, FL · in person or remote