Who will buy your software company, and what their technical review looks for

A founder preparing a sale usually does not know who will end up across the table. It might be a larger software company in the same market, a private equity fund looking for a platform, a portfolio company adding a product, or a single operator backed by a search fund and a bank loan. Each of them will send someone to read the technology. Each of them will read it for a different reason.

The systems they look at are the same: the repositories, the cloud account, the database, the people who run it all. What changes is the plan the buyer has for the product after closing, and that plan decides which findings matter, how severe they are and what they cost. A framework past its support date can be a footnote to one buyer and a price question to another.

This is a reviewer's guide to those differences, and to how a seller can prepare for several kinds of buyer at once without pretending to know which one will arrive.

Same systems, four different plans

A technical review starts from the buyer's thesis. Before reading any code, a careful reviewer asks what the buyer intends to do: keep the product running as it is, grow it fast, merge it into something else, or retire it once the customers have moved. The answer sets the weight of every one of our six layers, from ownership and infrastructure to the team.

Our engineering partner PERETZ covers the seller's side of this question in Buyer Universe: Why "Anyone Could Buy This" Means No One Will: buyers are defined by their reason to want a business, not by the size of their checkbook. The technical review is where that reason meets the evidence. A buyer who wants a capability will test whether the capability is real and portable. A buyer who wants a cash-generating product will test whether it keeps running without the people who built it.

Four broad types cover most software deals in the lower middle market. The lines between them blur, and a single fund can act as more than one type over time. The categories are still useful, because each one tends to ask a recognizable set of questions.

Strategic acquirers: the platform you move onto

A strategic acquirer is an operating company buying a product, a customer base or a team that fits its own business. It usually has its own engineers, its own security function and its own platform. The question behind its review is less "is this good software" and more "what happens when we combine it with ours."

What the review weighs

• Overlap. Which parts of the product duplicate what the buyer already has, and which parts are the reason for the deal. Code that will be retired matters less than the data and the customers that must move.
• Migration of data and customers. How clean the data model is, how customers are identified, whether accounts, billing records and history can be mapped into the buyer's systems.
• The buyer's own standards. Its security team often reviews the target against its internal policies: single sign-on, logging, encryption, vendor management. A product that passes a smaller buyer's review can fail a large company's checklist on items that were never a problem before.
• Open-source licenses. If the buyer will ship your code inside its own product, copyleft obligations such as those under the GPL or AGPL can reach further than they did while the product stood alone. That reading belongs to counsel, with the reviewer's inventory as the input.
• The engineers who matter for the transition. Not the whole team, but the few who understand the parts the buyer wants to keep.

A strategic buyer often cares less about elegant code than a seller expects, and more about the boring facts of integration: who holds the accounts, how identity works, what the contracts say about moving customer data. Its integration estimate can be large, and the review exists to put a range on it.

Private equity platforms: the base for growth

A platform acquisition is the first company a fund buys in a market, with the intent to grow it and usually to add other companies to it later. The fund rarely has its own engineers on the deal team. It buys the team along with the product, and it will write a 100-day plan soon after closing.

What the review weighs

• Scalability, in money. Whether cost per customer holds as the company grows, whether hosting and third-party fees scale with revenue or faster, and whether the architecture can carry the growth case in the fund's model. Our note on the technology behind SaaS gross margin covers that reading.
• The team that stays. Who holds the knowledge, who is likely to leave after closing, and how much of the system lives in one or two heads. Key-person risk is read as a property of the system, as set out in our note on key-person risk.
• Capacity to absorb add-ons. Whether the product, the infrastructure and the team could take on a second company: tenant model, identity, data structure, deployment discipline.
• The first 100 days and the first year. The fund needs findings it can turn into a budget and a sequence. The link between the report and that plan is described in from due diligence to the 100-day plan.

For a platform buyer, a finding that slows every future change weighs heavily, because the investment case depends on change. Missing tests, manual deployments and a framework near the end of its support tend to be rated higher here than for a buyer who plans to hold the product steady.

Private equity add-ons: fit and duplicates

An add-on is a company bought to join a platform the fund already owns. The review is often run with the platform's own technical leaders in the room, and it compares the target with a stack that already exists.

What the review weighs

• Fit with the platform's stack. Language, hosting provider, data stores, identity. A mismatch is not a defect, but it is a cost if the plan is to consolidate.
• Duplicate systems. Two billing systems, two customer databases, two cloud accounts, two support desks. Each duplicate is either a migration project or an ongoing cost of running both.
• Vendor commitments. Multi-year contracts with hosting or software vendors that cannot be ended early, so the duplicate keeps costing money after the plan says it should be gone. The terms are for counsel; the reviewer lists what exists and what it costs.
• Which product survives. If the platform and the add-on overlap, one product may be retired. Then the review prices the move of customers and data, not the repair of the retired code.
• Comparable findings. In a buy-and-build program the fund wants each add-on read with the same method and the same severity scale, so findings can be compared across companies.

Search funds and independent buyers: one operator

A searcher or independent sponsor typically buys one company, often with investors behind them and frequently with a bank loan, sometimes SBA-backed. The buyer usually becomes the chief executive. There is no technical department waiting to absorb the product, and the founder, often the main source of technical knowledge, will step back after a transition period.

What the review weighs

• Whether the product runs without the founder. Accounts in personal names, deployments only one person knows how to do, a long-time contractor holding the keys.
• Simplicity. A plain, well-known stack that a contractor or a small team can maintain is a real strength here. Clever architecture that needs specialists is a cost.
• The cost of replacing the founder's hours. Work the founder did unpaid or uncounted, from on-call duty to server updates, becomes a salary or a contract after closing.
• What lenders and investors can read. A lender may want comfort that the business keeps operating; investors want to see the main risks named and priced. The report has to be readable by people who are not engineers.

The searcher's side of this is covered in technical checks before buying a small software company.

What each buyer weighs, side by side

The table is a simplification, and real buyers mix these concerns. It is still a fair guide to where each review spends its time.

Most items in the right-hand column serve more than one row. That is the point the seller should take from it.

One finding, read four ways

The same fact about a product can land in very different places, because severity depends on the plan it is rated against. Three generic examples:

• The web framework is past its end of security support. A strategic buyer that will retire the product within a year or two may treat it as a transition risk to contain. A platform buyer may rate it High, because the growth plan runs through that code. For an add-on it depends on whether the platform uses the same framework. For a searcher it is a cost and a hiring question: who will do the upgrade once the founder steps back.
• Each customer runs on a separate deployment. To a strategic buyer it is a migration estimate. To a platform buyer it is a question about cost per customer and operations at scale. To an add-on buyer it is one more pattern the platform does not use. To a searcher it may be manageable at the current size, if the deployments are scripted and documented.
• Only the founder can release a new version. Every buyer will note it. The searcher, who is buying the founder's departure, will usually weigh it most heavily; a strategic buyer with its own engineers may weigh it least.

This is why a good report states which plan each finding was rated against, and why a seller should not read a buyer's report as a verdict on the product in general. Our report records that assumption next to the severity.

Preparing without guessing the buyer

A seller and its advisor may have a view on the likely buyer types, but the process often brings surprises, and a buyer list is the advisor's work, not the reviewer's. Building the technical story around one imagined buyer tends to backfire. Over-preparing for an integration that never happens can leave a platform buyer wondering why the company spent a year on it.

A better approach is a common core that every reviewer will ask for, with a few modules that serve particular buyer types and can be shared when they are relevant. The core is mostly the same work every buyer rewards: control of the code and accounts, a current inventory, honest costs, documented operations. The modules are deeper material that one type will read closely and another will skim, such as data model documentation for a strategic buyer or a scaling analysis for a platform.

The technical section of the data room is where this lives, and its claims should match what the systems show, as discussed in the technology claims in a sale document. None of it is fast. Moving accounts out of personal names, writing runbooks and pricing known issues takes months of a team's time alongside normal work.

A seller's preparation checklist

• Code, cloud accounts, domains and app store listings are held by the company, with a list of who has admin rights.
• Everyone who wrote code, employees and contractors, has assigned their work in writing.
• A dependency and open-source license inventory exists and is current.
• Hosting, third-party service and license costs are listed by month for at least the last year, with what drives them.
• Every third-party service is listed with its owner, contract term and notice period.
• An architecture overview shows how the product is built and deployed, and how users sign in.
• Deployment, backup and recovery are written down, and a restore has been tested.
• A knowledge map shows who understands each critical area, and no area depends on one person alone.
• Known issues are listed with a plain impact and a cost range with assumptions.
• The data model is documented well enough for an outsider to map customers, accounts and billing.
• Security policies exist, and there is evidence they are followed, not only written.
• The founder's technical hours are known, so the cost of replacing them can be stated.

Each item serves at least two of the four buyer types. Together they cover most of what any first technical request list will contain.

What to do next

If a sale is six to eighteen months away, exit readiness builds that core with you: a baseline across the six layers, a fix plan, monthly tracking and a mock review, without assuming a particular buyer. Closer to launch, vendor due diligence produces a seller report and a buyer report from one review, written so a strategic acquirer, a fund and a searcher can each find what they weigh. If an offer has already arrived and you need to know where you stand, a red-flag memo shows the findings that could matter most to that buyer.

Whoever the buyer turns out to be, their reviewers will read the same systems. The work is to make sure those systems answer the questions of more than one of them.

Questions