£200m Exit Checklist: Tech Org Readiness for Sale

I was CTO at Vanarama for seven years. We started somewhere around the £20m valuation mark and we sold to AutoTrader at £200m. Most of the work that made that exit possible was not glamorous engineering. It was the year and a half of unsexy preparation that meant the acquirer’s diligence team did not find anything that surprised either side.

This checklist is what I wish someone had handed me three years before that exit. It is not a maturity model and it is not a generic SOC2 prep guide. It is the nine areas where acquirers in the £20m–£500m range actually look on day one — what they check, what good looks like, what most tech orgs get wrong, and how to fix the gap.

If you are reading this because a sale is on the horizon, the most important thing I can tell you is that exit preparation is a 12–18 month exercise, not a 3-month one. Founders who start three months out pay for it. Founders who start 18 months out get to argue from a position of evidence. There is no shortcut to evidence.

Why Acquirers Inspect What They Inspect

Acquirers in this size band are buying three things: a customer base, a team, and a piece of technology that produces revenue. The diligence process exists to verify that those three assets are what the seller’s CIM says they are, that the risks are knowable, and that the integration cost is bounded.

What surprises first-time sellers is how little of the diligence is about pure code quality. Acquirers expect technical debt. Every system has it. What they do not tolerate is uncertainty — about who owns the code, about what licences govern it, about how it behaves under load, about how the team would respond to incidents. Uncertainty translates directly into price chips, escrow holdbacks, or earn-out structures that move risk back to the seller.

The job of pre-exit preparation is to convert uncertainty into evidence. The nine sections below are the areas where evidence is most readily inspected and most often missing.

1. Code Ownership and Source Control Hygiene

What acquirers check. Who wrote what. Is every commit traceable to an identified author with a signed contributor agreement or employment contract that assigns IP? Are there contractors in the history whose contracts did not include IP assignment? Is the repository structure coherent — monorepo or polyrepo with documented rationale — or is it a sprawl of unrelated repositories with unclear ownership?

What good looks like. Every commit in the production repositories has a known author covered by an IP assignment. Contractor work is either re-papered with retroactive IP assignment or quarantined and re-implemented in-house. Repository structure is documented. There are no “shadow repositories” — private GitHub accounts holding production code, contractor laptops with the only copy of a critical service.

What tech orgs typically get wrong. Early-stage contractors who built load-bearing services on a handshake agreement five years ago. Founder commits made under personal email addresses before there was a corporate domain. Open-source projects the founder maintains personally that have leaked into the production codebase. None of these are uncommon. All of them surface in diligence and all of them require legal remediation that takes weeks rather than days.

How to fix it. Run a commit-author audit twelve months before the earliest realistic exit date. Categorise every author. For uncovered contributors, choose one of: re-paper with retroactive IP assignment, formally settle and re-implement, or document the residual risk and reserve for it. The point is not to be perfect — it is to be able to answer the acquirer’s questions with paperwork rather than excuses.

2. Dependency Licence and SBOM Audit

What acquirers check. What open-source dependencies are you shipping with? What licences govern them? Are any of them GPL, AGPL, or source-available licences that could create distribution obligations or commercial restrictions? Can you produce a software bill of materials (SBOM) on demand? Are transitive dependencies mapped, or only direct ones?

What good looks like. A current SBOM generatable in CI for every deployable artefact. A documented allowlist of permitted licences with rationale. AGPL and source-available dependencies either avoided, licensed commercially, or quarantined behind clear architectural boundaries. Transitive dependencies inventoried. A response plan for high-severity CVEs that names the team responsible and the SLA.

What tech orgs typically get wrong. Direct dependencies look fine; transitive dependencies include something with an awkward licence buried four levels deep. AGPL components included in the codebase because someone copied a Stack Overflow snippet without checking. Forks of upstream projects where the original licence has been silently lost. Dependencies pinned to versions with known critical CVEs that nobody has scheduled the upgrade for.

How to fix it. Use a licence-scanning tool (FOSSA, Snyk, GitHub’s dependency review, Black Duck) and run it in CI. Generate SBOMs in CycloneDX or SPDX format on every build. Establish a licence policy and enforce it through the CI gate. For pre-existing problems, plan the remediation explicitly — replace, license, or carve out — and document the trail. Acquirers are forgiving of historical issues that have a remediation timeline. They are not forgiving of unknown unknowns.

3. Security Posture

What acquirers check. Access reviews — who has access to what, when was that access last reviewed, can you produce the audit log? Multi-factor authentication on every production-relevant system. Secret management — are credentials in a secrets manager or in environment files committed to the repository? Audit logging on production systems. An incident-response runbook. A penetration test from a recognised firm within the last twelve months.

What good looks like. Quarterly access reviews with documented sign-off. MFA mandatory on every production system, GitHub, cloud console, and any tool with production data access. Secrets in a managed vault (AWS Secrets Manager, HashiCorp Vault, Doppler, 1Password Secrets Automation). Audit logs retained for a defensible period — typically 12 months minimum. An incident-response runbook that has been tested with a tabletop exercise. A current penetration test report with remediation status for each finding.

What tech orgs typically get wrong. “We meant to do the access review last quarter.” Long-lived service accounts with credentials in the repository. Audit logging enabled but never centrally aggregated. An incident-response runbook that exists as a Google Doc nobody has opened in two years. A penetration test from three years ago with findings still open.

How to fix it. This is the section that takes the most calendar time to do credibly, and it cannot be backdated. Start now. A reasonable pre-exit posture is SOC2-equivalent controls implemented and demonstrated, even if formal certification is left for the acquirer to absorb. Many of these controls also reduce day-to-day operational risk, so the work is not pure deal-prep — it earns its keep regardless.

4. Customer Data and Privacy

What acquirers check. Do you know what personal data you hold and where? Is there a data inventory and a record of processing activities (ROPA)? Have you mapped lawful basis for each processing activity under UK GDPR or equivalent? Do you have data processing agreements (DPAs) with every sub-processor? Can you fulfil a subject access request or data export within the statutory window?

What good looks like. A current data inventory mapping every customer dataset to its purpose, retention period, and storage location. A ROPA covering all material processing activities. DPAs in place with every sub-processor and reviewed annually. A tested data-export capability — both subject access requests and full-account exports for the customer. A data-retention policy that is enforced in code rather than aspired to in policy documents.

What tech orgs typically get wrong. “We are GDPR compliant” as a statement without the supporting paperwork. Customer data replicated into developer environments and analytics warehouses without a clear retention policy. Sub-processors added to the stack without DPAs being updated. A subject access request that takes a frantic week to fulfil because the data is scattered across six systems with no single export path.

How to fix it. Treat data governance as a first-class engineering concern rather than a legal-team artefact. Build the inventory in a queryable format. Make data lineage visible. Automate retention enforcement. Run a fire-drill subject access request twice a year. The acquirer will run their own version of that fire drill during diligence, and the result will inform the deal economics.

5. Production Observability

What acquirers check. Do you know how the system is actually performing? Can you produce uptime data for the last six to twelve months with a credible methodology? Error rates trended over time? An incident log showing time-to-detection, time-to-mitigation, and root-cause analysis? A customer-facing status page?

What good looks like. An uptime SLO measurable for the last six months minimum, ideally twelve. Error rate tracked over time with named owners for regressions. An incident log with timing and root cause for every customer-impacting event. A customer-facing status page that is updated in real time during incidents. Synthetic monitoring on the critical user journeys. Real user monitoring (RUM) for the customer-facing surfaces.

What tech orgs typically get wrong. Uptime claims based on the deployment platform’s dashboard rather than the customer’s actual experience. Incidents that happened and were resolved but never written up. A status page that has not been updated in two years. Observability vendors paid for but never properly instrumented. Alerts that nobody acknowledges because they fire too often to be meaningful.

How to fix it. At Vanarama we tracked the metrics that mattered to the customer’s actual experience, not the metrics the dashboard happened to surface. The discipline is to define what “the system is working” means from outside the building, instrument that, and trend it. Tools matter less than the discipline of treating production observability as a product surface in its own right. If you have not been running the discipline, start now and accept that the first six months of data will be the baseline you defend.

6. Engineering Metrics That Read Like Financial Reporting

What acquirers check. Engineering cost per customer, per region, or per product line. The DORA metrics — deployment frequency, change lead time, change failure rate, mean time to restore. Headcount efficiency benchmarked against comparable companies. The unit economics of the engineering function expressed in the same vocabulary the rest of the business uses.

What good looks like. A dashboard the CFO and the CTO can both read showing how engineering cost flows into the business. DORA metrics tracked monthly with a credible measurement methodology — not vibes. The ability to answer “what does it cost us to onboard a new customer” with a number that includes engineering load. A clear story about where engineering spend is going and why.

What tech orgs typically get wrong. Engineering metrics that exist in a dashboard nobody outside engineering reads. DORA metrics measured incorrectly — counting all PRs as deployments, or measuring lead time from PR-open instead of from first commit. Cost-per-customer numbers that include sales and marketing but exclude the engineering allocation. A board pack where the engineering page is structurally different from the finance pages and therefore opaque to non-technical readers.

How to fix it. Borrow the format of the rest of the business. If finance reports unit economics, report engineering unit economics in the same shape. If sales reports a funnel, report the engineering delivery funnel in the same shape. The point is not vanity metrics — it is to make engineering legible to non-engineering board members and acquirers. Acquirers consistently underprice tech organisations whose metrics they cannot read.

7. Documentation and Bus-Factor

What acquirers check. For every load-bearing system, who are the named owners? Is there more than one? Is there a runbook? Are the load-bearing architectural decisions written down somewhere — architecture decision records (ADRs), design docs, a wiki? What happens if a specific named individual leaves tomorrow?

What good looks like. Every critical system has at least two named owners. Every critical system has a runbook covering deployment, common incidents, dependencies, and escalation. ADRs exist for the load-bearing choices — the database, the cloud provider, the framework, the major architectural patterns. The team can name the top three bus-factor risks without consulting a document.

What tech orgs typically get wrong. A founder-engineer who built the original system and is the only person who fully understands it. A wiki that documents everything except the things that actually matter. ADRs that exist for new decisions but not for the original load-bearing choices. Senior engineers with “I’ll write that up next quarter” hanging over them for two years.

How to fix it. Bus-factor is the cheapest section to improve in absolute terms and the slowest to improve credibly. You cannot manufacture knowledge transfer by writing a runbook the night before diligence. Pair the load-bearing engineer with a secondary owner six to twelve months out. Have them write the runbook together. Have the secondary owner run an incident solo, with the original owner watching. Acquirers can spot manufactured documentation and will discount it accordingly.

8. Vendor and Contract Estate

What acquirers check. Every SaaS contract, every infrastructure provider, every third-party API that the product depends on. Renewal dates, termination clauses, change-of-control clauses, pricing schedules. Are any high-leverage vendors locked in for terms that survive the acquisition? Are any vendors offering pricing that would change if a larger acquirer absorbed the contract?

What good looks like. A contract register listing every material vendor with contract value, renewal date, notice period, change-of-control language, and named internal owner. High-leverage vendors negotiated within the last twelve months on terms that read sensibly to an acquirer. Pricing that does not contain growth clauses likely to detonate post-acquisition. A clear story for any contract with awkward terms — either renegotiate, or document the residual risk explicitly.

What tech orgs typically get wrong. Vendors auto-renewing on three-year commits at unfavourable rates because nobody owns the renewal calendar. Change-of-control clauses that require the vendor’s consent, hidden in clauses nobody read at signing. Critical infrastructure on a contract that ends three months after the projected exit close, with no clear continuity plan. Vendor pricing that scales nonlinearly with usage and would explode under the acquirer’s larger footprint.

How to fix it. Build the register. It is administrative work but it pays for itself in the diligence room. For high-leverage vendors, negotiate change-of-control terms before you start exit conversations — once a deal is rumoured, the vendor’s negotiating position improves materially. For contracts with awkward terms you cannot fix, surface them in the disclosure schedule rather than letting the acquirer’s lawyers find them.

9. Roadmap-to-Acquirer Fit

What acquirers check. Does your 12-month roadmap read sensibly to an outsider? Is the technical debt narrative honest — does it name the load-bearing legacy components and the modernisation plan, or does it pretend everything is greenfield? Have you sketched the integration path with the acquirer’s stack, even at a high level? Is the roadmap aligned with the customer evidence in the data room?

What good looks like. A roadmap that names the three or four major bets the company is making over the next twelve months, why, and what would invalidate each one. A debt register that is candid about the load-bearing legacy. An integration sketch that shows you have thought about how the acquirer might absorb the technology — even if the eventual answer turns out to be different. A roadmap that the customer success and product teams recognise as theirs, not a separate engineering wishlist.

What tech orgs typically get wrong. A roadmap that reads as a feature-bingo card unconnected to strategy. A debt register that is either absent or so sanitised it is obviously incomplete. Treating the acquirer-fit question as something to handle after the LOI rather than during it. Two parallel roadmaps — the optimistic one for the data room and the realistic one for internal planning.

How to fix it. Write the roadmap once. The version that goes in the data room is the version the engineering team uses. Have the debt narrative reviewed by someone outside the company who can stress-test it for credibility. For acquirer-fit, the question is not “do we know exactly how this will integrate” — it is “have we thought about it enough that the acquirer believes we will integrate well.” Those are different bars.

What Vanarama Got Right. What We Got Lucky On.

What we got right at Vanarama was building a tech organisation that was legible from outside engineering. The metrics that mattered were tracked. The runbooks existed. The data inventory existed. We had spent years making the engineering function explicable to a non-technical board, and that paid off when AutoTrader’s diligence team arrived. The diligence room felt like a continuation of the conversations we had already been having internally — not a new performance.

What we got lucky on was the calibre of the engineers we had hired in the early years. Two of them had become the load-bearing figures for the most critical systems by the time of the exit, and the bus-factor risk was real even if we had documented around it. If either of them had decided to leave during the deal, the integration risk would have been priced very differently. We also got lucky on the dependency-licence side — a clean stack chosen for engineering reasons turned out to be a clean stack for legal reasons too, which would not have been the case if we had moved faster on a few earlier architectural choices.

The pattern, looking back, is that the things we deliberately invested in over years — observability, documentation, hiring quality — held up under diligence pressure, and the things we did not deliberately invest in held up only because we got lucky. The lesson I would give a founder approaching an exit now is: do not rely on luck for any of the nine sections above. The cost of preparing each one is bounded; the cost of being caught short on any one of them, with a deal in motion, is not.

Getting Help

If you are 12–18 months from a realistic exit and want to pressure-test where the gaps are, our fractional CTO services and interim CTO London engagements include exit-readiness diagnostics for founders who want a candid second opinion before the diligence team arrives.

For the buy-side perspective on the same checklist, our technical due diligence playbook covers what an acquirer’s investigators actually do once they are in the room. For founders weighing whether to bring in fractional senior engineering leadership at all, our breakdown of fractional CTO vs interim CTO vs CTO-as-a-service is the right place to start.

For the underlying technical work that often surfaces during exit preparation — modernising the load-bearing legacy components and making honest build-versus-buy decisions on the rest — our guides to legacy modernisation and build vs buy cover the engineering side of the same problem. For the strategic framing that should sit above all of it, see our work on digital strategy.

Most exits are won or lost in the eighteen months before the LOI lands. The work above is unglamorous, it does not feel like product progress, and it is the single highest-leverage thing a tech organisation can do in that window.