The exit-readiness checklist: technology and brand before a raise or a sale

A raise or a sale is coming.

Soon someone will ask to see your code, your analytics and your story.

Here's the twist: much of what they'll look at is ordinary. A licence file. A consent banner. A second person who can deploy.

Ordinary things are cheaper to fix on your own schedule than on a buyer's.

This guide gives you nine short checklists, one per area, from code to the data-room story.

It's the list we use in our exit-readiness review, and the standard we hold this site to.

It is not legal advice.

1. What exit readiness means

Exit readiness is the state of a company whose technology, data and story can stand up to a buyer's or investor's review without surprises.

Technical due diligence is that review. An outside team checks your code, infrastructure, security, licences and people, to price the risk they're taking on.

Being ready doesn't mean being perfect. It means knowing your weak spots, fixing the cheap ones and explaining the rest.

2. The nine areas at a glance

Use this table as the index. Each row has its own checklist below.

3. Code and architecture

The aim isn't perfect code. It's code another team can change with confidence.

• One architecture diagram a new engineer can follow in one sitting.
• Repositories owned by the company, with nothing that lives only on a laptop.
• Dependencies current, or a note on which aren't and why.
• A known-debt list: what's fragile, what it would take to fix, and what you chose to live with.
• Reproducible environments: staging matches production, and deploys don't depend on one machine.
• Infrastructure written down, ideally as code.
• No dead features: old code paths and forgotten feature flags removed.

4. Tests and CI

Tests are how you prove a change won't break the business. CI is how you prove they actually run.

• End-to-end tests on the flows that make money: sign-up, checkout, the core job.
• Tests run on every change, and a failing test blocks the release.
• Lint, type checks and formatting in the same pipeline.
• Flaky tests fixed or removed, not re-run until they pass.
• A preview environment for every change, so someone can click through it.
• A visible history: how often you deploy, and how often a deploy goes wrong.

5. Security basics

Broken access control is first on the OWASP Top 10 for 2025, and software supply chain failures are third (OWASP, Sep 2026).

Neither needs an exotic attack. Both need basics done every time.

• Multi-factor sign-in on every admin, cloud, code and email account.
• No secrets in the repository, including its history.
• Access matches the org chart: leavers removed, shared logins replaced with named accounts.
• Permissions checked on the server for every request, not just hidden in the interface.
• Dependencies patched on a schedule, with automated alerts.
• Backups restored as a test at least once, with the date written down.
• Errors and security events logged, and someone assigned to watch them.
• Security questionnaire answers drafted once and kept current.

6. Licences and third-party code

A buyer is paying for what you own. This checklist shows that you own it.

• A licence inventory of every open-source dependency. A software bill of materials does this; CISA describes one as a nested inventory of the ingredients that make up software components (CISA, Sep 2026).
• Copyleft checked. Under the GNU AGPL, if you run a modified program on a server and let users interact with it, they must be able to download its source (GNU Project, Sep 2026). Know whether you use AGPL code, and how.
• IP assignments signed by every employee, contractor and agency that wrote code, including the early ones.
• Fonts, images and icons licensed for commercial use, with the receipts.
• Third-party APIs and data sources used within their terms.
• Paid tools on company accounts and a company card.

7. Accessibility: WCAG and ADA exposure

The US Department of Justice says the law's requirements for businesses open to the public cover what they offer on the web (US Department of Justice, Mar 2022).

For businesses, it has no regulation setting detailed standards. It points to WCAG as helpful guidance (US Department of Justice, Mar 2022).

Lawsuits are common. There were 3,117 federal website-accessibility lawsuits in 2025, 961 of them in Florida (Seyfarth, Mar 2026).

And most home pages fail. In 2026, 95.9% of the top million home pages had detected WCAG 2 failures (WebAIM, Feb 2026).

• A dated audit of key pages and flows against WCAG 2.2 AA, with automated and manual testing.
• Keyboard and screen-reader checks on sign-up, checkout and every form.
• Fixes in the code, not an overlay widget. The FTC ordered one overlay vendor to pay $1 million over claims that its tool could make any website WCAG-compliant (FTC, Apr 2025).
• Automated accessibility tests in CI, so fixes stay fixed.
• An accessibility statement with a way to report problems.
• Any demand letters on file, and with your attorney.

8. Analytics and consent

Your growth story rests on your analytics. The numbers have to be right, and collected the way your privacy policy says.

Google's consent mode adjusts how its tags behave based on the visitor's choice (Google, Sep 2026).

In the basic setup, tags don't load until the visitor interacts with the consent banner. In the advanced setup, they load with consent denied by default (Google, Sep 2026).

Either way, Google says to set the default consent state on every page, before any command that sends measurement data (Google, Sep 2026).

• A tag inventory: every script, pixel and SDK, who added it, and why.
• Nothing tracks before consent where consent is required. Test it in a clean browser.
• The banner, the privacy policy and the code agree. Read them side by side.
• Key events documented: names, triggers, and which ones count as conversions.
• Conversions reconciled against the source of truth: payments, orders or the CRM.
• Internal and test traffic filtered out.

9. Data and privacy

Privacy law depends on where you and your customers are. Florida is one example.

Its statute requires covered businesses to take reasonable measures to protect personal information (Florida Statutes, Sep 2026).

It also sets a deadline for telling affected people about a breach: no later than 30 days after the business determines a breach occurred, or has reason to believe one did, with limited exceptions (Florida Statutes, Sep 2026).

• A data map: what personal data you collect, where it's stored, and who can see it.
• A vendor list: every processor, what data it receives, and the contract behind it.
• Retention rules, and proof that deletion actually happens.
• The privacy policy matches the code. If it doesn't, one of them changes.
• An incident plan: who decides, who notifies, and in what order.
• Real customer data kept out of test environments, or masked.
• Nothing sensitive in URLs, logs or error reports.

10. Documentation and bus factor

Your bus factor is the number of people who could leave before work stalls. If it's one, fix that first.

• A README that takes a new engineer from clone to running locally.
• Runbooks for deploys, rollbacks, restores and incidents.
• Decision records: why the big choices were made, in a sentence or two each.
• Credentials in a company password manager, not in inboxes or heads.
• Two people who can deploy, restore and reach every account.
• Every account on a company address: registrar, DNS, cloud, repositories, analytics, app stores.

11. Brand and the data-room story

The story is what people read first: the deck, the site, the one-line description. It has to survive the numbers behind it.

• One positioning line that the deck, the site and the founders all use.
• Every number sourced. Revenue, growth, customers: the same figure and date everywhere. On our own site, every figure lives in one file with its source.
• Proof with permission: customer names, logos and quotes you're allowed to use, in writing.
• Brand assets owned by the company: trademarks, domains, social handles and design files.
• A brand book, so the company looks the same when the founder steps back.
• A website that matches the deck: the same claims, the current team, no dead pages.
• A data-room index in the deck's order, so every claim has a document behind it.

12. How our exit-readiness review works

We run the checklist for you and write down what we find.

• Two to three weeks, ending in a written report.
• Jesus reviews the technology: code, tests and CI, security basics, WCAG accessibility, analytics and consent, and licences.
• Elizabeth reviews the story: positioning, the deck, the site and the data-room narrative.
• A fixed fee of $12,000, credited to the next phase if you continue with us.
• Alongside your advisers. We don't give legal advice. We work next to your attorney and your accountant.

13. Do this first

Open a spreadsheet. List every account the company depends on: registrar, DNS, cloud, code, analytics, email, app stores and payments.

Next to each one, write who owns it and who else can get in.

Any row with a personal email address, or only one name, is your first fix.