Ready before the buyer asks.
Exit readiness is a monthly program for founders who plan to sell in the next 6 to 18 months. We find what a buyer's reviewers would find, rank it by its effect on the price, and track the fixes until the technology is ready for diligence.
- For
- Founders and boards planning a sale
- Timing
- Monthly, at least 4 months
- Fee
- Fixed monthly fee
- You get
- Baseline, plan, tracking, mock review
When there is time to fix, not just explain.
- You plan to sell in the next 6 to 18 months and want the technology to help the price, not hold it back.
- Your board or investors have asked whether the company would survive a buyer's technical review.
- A previous deal or financing slowed down in diligence, and you want the next one to go differently.
- The product was built fast, by a founder and contractors, and much of it lives in people's heads.
- Less than four months left? A red-flag memo or vendor due diligence fits better.
From baseline to a clean review.
Baseline
A review of all six layers, as a buyer would order it, and a list of findings with severity and cost to fix.
Fix plan
Findings ranked by their effect on price and risk, with owners, dates and budgets your team can live with.
Ownership and access
The cheap, fast fixes that could stop a deal on their own: accounts, assignments, licenses, offboarding, secrets.
Data, resilience, knowledge, code
Privacy gaps, a tested restore, runbooks and a second person on critical parts, then the code items that matter most.
Tracking
A monthly check of what was fixed, what slipped and what changed, with a one-page status for the board.
Data room
The technical part of the data room prepared as you go, so it matches what reviewers will find.
Mock review
A review run the way a buyer would run it, so the first real one holds no surprises.
Vendor due diligence
Optional. Many founders finish with a report buyers can read, built on the mock review.
Ownership and access before code.
Founders often want to start with the code, because that is where engineers feel the pain. Buyers see it differently. A dated framework is a cost they can price. A repository in a former contractor's account, or customer data nobody can map, is a question they cannot price, and those questions stall deals. So the plan starts at the bottom of the layers and works up.
- 1 · Ownership
- Repositories, cloud accounts, domains and app store listings moved into the company's name. Missing IP assignments signed. An open-source license inventory.
- 2 · Access
- Former staff and agencies removed, multi-factor authentication everywhere, shared logins replaced, secrets taken out of the code.
- 3 · Data
- Personal data mapped, retention set, test copies masked, the privacy policy matching what the system does, agreements in place with processors.
- 4 · Resilience
- Backups restored at least once, with a written procedure, and monitoring that tells someone when things break.
- 5 · Knowledge
- Runbooks for deployment and recovery, and a second person who can do what only one person can do today.
- 6 · Code
- End-of-support frameworks, tests on the paths that carry money, and a written plan for the debt that remains.
One thing we usually advise against: starting a rewrite or a large migration shortly before a sale. A stable, older stack with a clear plan reads better to a buyer than a migration half done.
One page a month for the board.
Every month the board gets the same one-page status: open and closed findings by severity, what moved, what slipped and why, decisions needed from the board, budget used against the plan, and any risk to the sale timeline. Your M&A advisor can receive it too, so the technical story they will tell buyers is built on facts from the start.
A finding is closed only when we have seen the evidence, not when someone says it is done. That is the standard a buyer's reviewers will apply.
The technical section of the data room.
Built during the program, kept current, and checked against what a reviewer would actually find.
- System overview and architecture, written for a reader who has never seen the product.
- Inventory of repositories, cloud accounts, domains and app store accounts, with owners.
- IP assignment records for employees and contractors, and the open-source license report.
- Third-party services and processors, with their contracts and any change-of-control terms flagged.
- Security policies, access review records, incident log, and any penetration test or SOC 2 report.
- Backup and recovery procedure with the date and result of the last restore test.
- Data map and privacy documentation.
- Hosting cost history and the main drivers of the bill.
- The technical team: roles, contractors and how knowledge is shared.
- Known technical debt with its plan, and prepared answers to the usual buyer questions.
Who does the work, and the fee.
Your own team does most of the fixing, with our plan and checks. When you need more hands, our engineering partner PERETZ, under common ownership with The Structure, can do the work under a separate contract, or you can use any other team. It is never a condition. We review the result the same way in either case, and the mock review treats every fix equally.
The program has a fixed monthly fee, agreed in writing after a scoping call under NDA. It depends on the size of the product and the number of codebases and teams. Adding a product or a business unit is agreed in writing first. The minimum is four months, because the baseline, the first fixes and a mock review need that long. The mock review uses the same method as every review we run.
A program, not a promise.
- Not a sale process. We do not find buyers, arrange introductions or negotiate. Your M&A advisor does that.
- Not a rewrite. The goal is a product a buyer can understand and own, not a new one.
- Not outsourced engineering. The fixes are done by your team or a team you choose, under its own contract.
- Not a valuation. We rank findings by their likely effect on price and terms; your advisors value the company.
- Not legal or tax work. Assignments, contracts and privacy terms go to your counsel; we tell them what the system shows.
Common questions.
How early should we start?
Six to eighteen months before going to market is the useful window. Earlier, priorities change too much; later, there is no time to fix what matters. With less than four months, a red-flag memo or vendor due diligence fits better.
Is this the same as vendor due diligence?
No. Exit readiness prepares the company; vendor due diligence documents it for buyers. Many founders do the first and finish with the second, which is shorter and lighter on your team because the mock review has already done much of the work.
Will it disrupt the team?
We work with one technical contact and agree a monthly rhythm. Most of the time goes into fixes your team would need to make anyway, and the plan is built around your roadmap, not in place of it. Interviews happen at the baseline and the mock review, not every week.
What gets fixed first?
Ownership and access: accounts in the company's name, signed IP assignments, former staff removed, secrets out of the code. These are cheap and fast, and they are the findings that can stop a deal on their own. Code work comes later.
Do our staff need to know we plan to sell?
No. Internally, the program can simply be a technical health check, which is what it is. We work with the people you choose, phrase our requests to fit the boundary you set and send the monthly status only to the people you name.
Can you guarantee a clean buyer review?
No one can. What we can do is find what a buyer's reviewers would find, help you fix or document it, and run a mock review the way they would. Whatever remains is known, with a plan and a cost.
What does the mock review produce?
A report written the way a buyer's report would be: findings by severity, evidence, impact and cost to fix. It shows what is left before you go to market and becomes the starting point for vendor due diligence if you order one.
Can we stop the program early?
The minimum is four months, because the baseline, the first fixes and a mock review need that long. How the program continues or ends after that is set in the engagement letter before we start, so a change in the sale timing is planned for.
Preparing a sale or looking at a target?
We reply within one business day. NDA before any documents change hands.