A technical baseline before the banker

A founder who plans to sell in a year or so usually starts with the numbers: revenue quality, churn, margins, the story a banker will tell. The technology tends to come later, often on the day the buyer's reviewers ask for repository access during exclusivity. By then very little about it can still be changed.

That order is backwards for a simple reason. Most of what a buyer reads about a business is history. Last year's revenue, the customer list and the contracts signed three years ago are what they are. The technology is different. Accounts can move into the company's name, a backup can be restored, a second engineer can learn the billing code. Months before a process, those are tasks. Inside one, they are disclosures.

This article is for founders of software companies six to eighteen months from a sale. It covers what a technical baseline is, how to decide what to fix and what to disclose, how the baseline feeds the banker's materials and the data room, and how an exit readiness program runs month by month.

The part of the business you can still change

Once a banker launches a process, the company is on record: the information memorandum describes it, the data room documents it, every bidder reads the same version. Changes after that point are not forbidden, but each one has a price. A security fix made during exclusivity raises the question of why it was needed. A migration started after the teaser is a moving part the buyer has to price. A new engineering lead hired weeks before signing is a key-person question, not an answer to one.

Before the process, the same work is ordinary operations. Nobody asks why the team rotated its secrets in March. By the time a reviewer looks, the fix has months of evidence behind it. That evidence is the point. A buyer's reviewers rarely accept "we fixed it last week" at face value. They ask whether it stays fixed.

There is also the matter of position. A problem the buyer finds during exclusivity is found at the moment the seller has the least room: one bidder, a deadline, a team already stretched by diligence requests. The same problem found by the founder a year earlier is a line in a plan.

Our engineering partner PERETZ makes the general case for this order of work in Before You Hire Bankers, Diagnose the Business: understand what is really going on in the business before choosing a transaction. A technical baseline is the technology part of that diagnosis, written the way a buyer's reviewer would write it.

What a technical baseline looks like

A baseline is a review of the company as a buyer's technical due diligence would see it, done for the founder while there is still time to act. It is not a code quality score or a penetration test. It has three parts.

The six layers, read honestly

Every one of the six layers is read in full. "Honestly" carries weight here. The founder is the client, but the baseline is written as if a skeptical buyer had paid for it. A baseline that tells a founder what they hope to hear is worse than none, because it only moves the surprise into exclusivity. For each layer, the question a buyer will ask is short:

• Ownership & IP. Does the company, not a person or an agency, hold every account, repository, domain and license, and did everyone who wrote code assign it?
• Infrastructure & cost. What does it cost to run, how does that grow with customers, and has anyone ever restored a backup?
• Data & privacy. Where does personal data live, who can reach it, and does that match what customers were told?
• Code & architecture. Which parts are past end of support, what is tested, and how safely can the product change?
• Security & access. Who still has access who should not, where are the secrets kept, and what incidents happened?
• Team & knowledge. What breaks if one person leaves, and what is written down?

Each finding rated and costed

Each finding carries a severity on the scale a buyer's report would use: Critical, High, Medium or Low. It comes with the evidence behind it, the business impact in plain words, and a cost and time to fix stated as a range with its assumptions. The format is the same as in the report a buyer receives. That sameness is deliberate. The founder learns to read findings the way the other side will.

A fix plan with owners and costs

The findings then become a plan. For each one: a decision (fix, disclose or leave), an owner on the founder's team or an outside team, a budget range, and a date that lands before the data room opens. A plan without owners is a list; one whose owners have a full roadmap is a wish.

Choosing what to fix and what to disclose

Not every finding should be fixed before a sale. Some cannot finish in time. Some cost more than the problem they solve. Some create new risk while they are in progress. Four questions sort most findings:

1. Can it be finished, with evidence, before the data room opens? A fix half done is a new finding.
2. Is the cost of fixing in sensible proportion to what the finding could do to price or terms? Your advisors judge the price side. The baseline gives them the cost side.
3. Does it depend on people outside the company, such as a former contractor's signature or a vendor's consent? Start those first, because they run on someone else's calendar.
4. Could the work itself break something a buyer will test, such as billing, uptime or a customer integration?

For the most common findings the answers tend to fall into a pattern. Treat it as a rule of thumb; each company decides on its own facts.

Never start a big migration just before a sale

The most expensive mistake in this window is a large project begun because a sale is coming: a rewrite, a move to another cloud provider, a switch of the core framework, a new billing system. Projects like these tend to run longer than planned even without a deal on top. If one is half done when buyers arrive, they see two systems instead of one, a team split across both, new incidents, and a cost to finish that is now theirs. A stable older stack with a clear, costed plan almost always reads better. Our article on technical debt in due diligence explains why a rewrite is rarely the right answer.

The exception is a hard external date that falls inside the process, such as an app store requirement or a provider ending support for a runtime the product depends on. Then scope the work as narrowly as possible and finish it well before launch, so the reviewer sees a completed change with some history.

Disclosure is not confession

A finding that remains goes into the data room with its evidence, its severity and its plan. That reads very differently from the same finding discovered by a buyer, which leaves them wondering what else they have not found. How a known finding is reflected in disclosure schedules or the purchase agreement is a question for counsel. The baseline gives counsel facts to work from.

One story, one set of facts

The banker writes the story: the teaser, the information memorandum, the management presentation. The data room holds the evidence. Buyers' reviewers read both and look first for disagreements. A memorandum that calls the platform "modern and scalable" next to a data room showing an unsupported framework and a single database server does more damage than either fact alone, because it teaches the reader to distrust the rest.

The baseline lets both be written from the same facts. In practice:

• Give the banker a one-page technical summary drawn from the findings: what the product runs on, what it costs to run, what changed in the last year, and what remains with a plan.
• Replace adjectives with facts a reviewer can check: the date of the last restore test, hosting cost against revenue, how many people can deploy and recover the system.
• Tie security claims to documents that exist, such as a penetration test or a SOC 2 report, with their dates and scope.
• Make every claim in the technology section of the memorandum point to a document in the data room.
• Draft answers to the questions buyers usually ask from the same register of findings, so every answer matches every other.

What belongs in that section of the data room, and how a reviewer reads it, is covered in the technical section of the data room. The short version: build it during the program, not in the last month, so it describes the company as a reviewer will find it.

An exit readiness program, month by month

Exit readiness is a monthly program of at least four months, running from the baseline to a mock review. The table shows its shape for a founder with about a year before the banker launches. With less time, the steps compress. With less than about four months there is not enough time to fix things and prove the fixes, and a different engagement fits better.

Two rules hold through the whole program. A finding is closed only when the evidence has been seen, not when someone reports it done; that is the standard a buyer's reviewers will apply. And the plan fits around the product roadmap rather than replacing it. A buyer reads growth as closely as hygiene.

Most founders keep a planned sale from most of their staff. Internally, the program can run as a technical health check, which is what it is. Access follows the same protocol as any review: read-only, named accounts, closed at the end.

The slowest work is rarely the code. Reducing dependence on one engineer means a second person who has actually deployed and recovered the critical parts, which takes months, not a handover document. See key-person risk for what reviewers look for.

When vendor due diligence fits instead, or after

Vendor due diligence is a different tool. Exit readiness changes the company. Vendor due diligence documents it for buyers: the same independent review a buyer would order, commissioned by the seller, producing a seller report with priorities and advice and a buyer report written for the data room.

It fits instead of exit readiness when too little time is left to fix much, usually under four months, or when the technology should already be in order and only needs testing and writing down. It fits after exit readiness as the last step. It is then usually shorter and lighter on the team, because the mock review has already done much of the work.

Neither replaces the buyer's own review. Buyers usually still run one, but they start from facts instead of from nothing, and the team answers each question once. If the only question is whether anything would stop a deal, a red-flag memo answers that narrower question first.

A founder's baseline checklist

Before the first call with a banker, aim to answer yes to most of these, with evidence rather than memory:

• Every repository, cloud account, domain, app store account and paid service the product needs is listed, with the company as the holder.
• Every person in the commit history maps to a signed IP assignment, or to an agency contract that assigns the work. See ownership gaps that stop a software deal.
• An open-source license scan exists, and the use of each copyleft component is explained.
• Former employees, contractors and agencies have no remaining access; admin accounts are named and use multi-factor authentication.
• No secrets sit in the code, the build configuration or shared documents.
• A backup has been restored within the last few months, and the time it took is written down.
• The hosting bill for the last twelve months is explained, with its main drivers.
• Personal data is mapped, and the privacy policy matches what the system actually does.
• Frameworks and runtimes past or near end of support are listed, each with a plan and a cost range.
• At least two people can deploy and recover the product from written runbooks.
• Every claim about the technology in the banker's materials points to a document in the data room.
• No rewrite or large migration is running, or planned to start, before the process ends.

What to do next

If you are twelve months or more from a process, start with a baseline and build the plan from it. At six months there is still time for ownership, access, recovery and documentation, but not for big projects. Under four months, document what is there and disclose what remains with a plan. None of this makes a sale fast or simple. It removes the avoidable surprises from a process that is demanding enough without them.

Our exit readiness program runs the baseline, the fix plan, monthly tracking, the data room technical section and the mock review. Vendor due diligence gives buyers a report they can build on. We do not find buyers, value the company or give legal advice; that stays with your banker and your counsel. We tell them what the technology shows.

Questions