The technology claims in your sale document, read by the reviewer who will test them

The technology section of a confidential information memorandum is usually one or two pages. It is written by a banker from a call with the founder, approved in a hurry, and rarely read again by the people who wrote it. It is read very closely by someone else: the reviewer the buyer hires once exclusivity starts.

That reviewer opens the memorandum before the repository. Each sentence about the technology becomes an item on the request list. "Proprietary platform" becomes a request for contractor agreements and a dependency inventory. "99.9% uptime" becomes a request for monitoring data. "The team can run without the founder" becomes a question about who deployed the last ten releases.

This article is written from that reviewer's chair. It takes the technology claims that appear most often in sale documents, and for each one says what a reviewer asks for, what usually breaks it, and how to word it so the evidence holds it up. It is for founders, boards and the advisors who draft these documents.

Every sentence becomes a request

A sale document makes promises at three levels of detail. The deck or management presentation states them in a line. The memorandum states them in a paragraph. The data room is supposed to prove them. A buyer's technical reviewer works backwards along that chain: claim first, then the document behind it, then the system itself through read-only access.

The reviewer is not hostile to the seller. The job is to tell the buyer where the technology matches the story and where it does not, with evidence. A claim that matches is a short line in the report. A claim that does not match is a finding, and it carries a severity rating, an impact and a cost to fix.

The useful question for a seller is not "does this sound good?" but "what will someone ask for when they read this, and do we have it?" A sentence that cannot answer that question is not ready to be printed.

Why an overstated claim costs more

Most software companies have the ordinary problems: an old framework somewhere, thin tests in one module, documentation that lags behind the code, one engineer who knows billing. A reviewer expects these. On their own they are neutral facts. They go into a fix plan, and the buyer prices the plan or carries it into the first year.

The same fact reads differently when the memorandum said the opposite. If the document says "no technical debt" and the reviewer finds a framework past its end of security support, the finding is no longer only about the framework. It is about the document. The reviewer has to ask what else was written the same way, and the buyer's team starts to test every other claim harder: revenue definitions, customer counts, retention. The review gets longer and the tone changes.

A modest claim works the other way. "The core application runs on a supported framework; two internal tools need upgrading, planned for the next quarter" will be confirmed by the review. The reviewer writes that management described the system accurately, and that line is worth more to a seller than any adjective. A credible document makes the remaining findings easier to accept.

There is a contractual side too. Statements in a sale document can end up next to the representations and warranties in the purchase agreement, and how far a seller is exposed for an inaccurate statement depends on the agreement and the law of the deal. That is a question for counsel, and a good reason to have counsel read the technology section before it goes out, not only the contract.

Claims about what the company owns

"Proprietary platform"

The reviewer asks what is actually yours. That means the list of people who wrote the code compared with signed employment and contractor agreements that assign their work, an inventory of open-source components and their licenses, and a list of the third-party services the product runs on. The claim usually breaks in one of three ways: the core is a licensed or white-label product with a custom layer on top; early code was written by contractors with no written assignment; or a copyleft component sits in a part of the product that is shipped to customers. The safer wording names the parts: "Our own application, written by our team and contractors under signed assignments, built on open-source frameworks and these third-party services." The gaps behind the claim are covered in what a technical due diligence reads.

"AI-powered"

The reviewer asks which models the product uses, who provides them, what the company built around them, and what each request costs. The claim breaks when the AI feature is a prompt sent to a third-party model with no evaluation set, no versioned prompts and no data the company has the right to use. It also breaks quietly when inference cost is missing from the gross margin. Say what the model does and what you built: "Uses a third-party language model to draft replies; our own work is the retrieval layer over customer documents and an evaluation set of real cases." The full test is in AI diligence: is it a product or a wrapper?

"No technical debt"

No reviewer has read a product with none. The claim invites a search, and the search always finds something: runtime support dates, missing tests where money moves, a release process that depends on one machine. Replace it with the known debt and the plan: "Known debt: the billing module has limited test coverage and the admin tool runs on an older framework version; both are scheduled, with estimates." That turns a future finding into a management decision. How reviewers size debt is covered in how technical debt is measured and put into a deal.

"Fully documented"

The reviewer asks for the documents and their dates, then asks who used them last. A practical test: could an engineer who has never seen the system deploy a release, restore a backup and rotate a key from what is written? The claim breaks on a README from years ago, an architecture diagram that no longer matches the cloud account, or runbooks that live in one person's notes. Say what exists: "Runbooks for deployment, restore and on-call, updated this year; architecture notes for the core services; gaps in the reporting module."

Claims about how the system runs

"Scalable"

Every product scales to some point. The reviewer wants to know which point and at what cost. The requests are hosting invoices for twelve months next to customer and usage numbers, any load test with its date and method, the usage of the largest customer, and the parts of the system that run on a single instance. The claim breaks when the cloud bill grows faster than revenue, when one database server carries everything, or when the largest customer already needs manual work. Give the facts instead of the adjective: current peak load, the largest tenant, headroom tested and when, and the cost per customer over the past year.

"99.9% uptime"

The figure sounds exact, so it is checked exactly. Over a 30-day month, 99.9% allows roughly 43 minutes of downtime. The reviewer asks how it is measured, by what tool, for which components, over what period, and whether planned maintenance is excluded. Then the incident log and any credits paid under customer service level terms. The claim breaks when it comes from a hosting provider's promise rather than the company's own monitoring, or when it covers the website but not the application. Wording that holds: "Measured by external monitoring of the login and core API, excluding announced maintenance, over the last twelve months; incident log available."

"Secure"

This word has no meaning a reviewer can test, so the reviewer tests the basics instead. The requests are the list of administrators and their multi-factor status, offboarding records for people who left, the date and findings of the last penetration test and what was fixed, a search of the code history for keys and passwords, and the incident log. The claim breaks on a shared admin login, a former contractor who still has access, a test report with open high findings, or secrets in the repository history. Name the controls and their dates. Avoid absolute statements such as "never breached" in a marketing document; whether and how to describe incident history is for counsel, who will also see what the logs can support.

"SOC 2 ready"

A SOC 2 report is issued by an independent auditor. A Type I report looks at whether controls are designed at a point in time; a Type II report looks at whether they operated over a period. "Ready" is not either. The reviewer asks what exists: a signed engagement with an auditor, a readiness assessment, written policies, and evidence that the controls have been running. The claim breaks when "ready" means a policy template and a compliance tool subscription. Say where you are: "Readiness assessment completed; Type I audit engaged for next quarter." If a report exists, say which type, which period and which systems are in scope, and put it in the data room.

"The team can run without the founder"

The reviewer asks who holds the owner role on the cloud and code accounts, who deployed recent releases, who answers when production fails at night, and when the founder was last away for more than a week. Commit history in billing, authentication and integrations shows who really knows those parts. The claim breaks when the founder holds the root credentials, approves every release and answers every hard question in interviews. Write what happened, not what is hoped: "Releases and on-call are run by two engineers; the founder took three weeks off last year and the product shipped twice." The reviewer's method is described in key-person risk in the technology.

Claim, evidence and safer wording

The same material for a drafting session. The wording is generic; your facts must come from your own systems.

Deck, memorandum and data room agree

A buyer reads the technology story three times: once in the deck or the management presentation, once in the memorandum, and once in the data room. The reviewer compares them line by line. Different numbers in different places read as carelessness at best, and they turn a fine fact into a question. The usual mismatches are small and avoidable: the deck says twelve engineers and the org chart shows five employees and seven contractors; the memorandum gives one hosting cost and the invoices another; the deck names one framework version and the repository runs an older one; uptime is quoted for a different period in each document.

The fix is one source of truth for the technology facts. Before anyone drafts, the technical lead writes a short fact sheet: each fact, its number or wording, the date it was true, and the data room file that proves it. The banker's team takes the wording from that sheet for every document, and any change happens on the sheet first. The technical section of the data room is then built from the same list, so each claim has a folder behind it.

Each document still has its own job. The deck states the claim in a line. The memorandum adds the definition and the period. The data room holds the evidence. In the management presentation, the technical lead, not the founder, should answer technical questions, in the same words. Our engineering partner PERETZ covers the whole company story, including the deck and the memorandum, from the seller's side in How to Present Your Company to a Buyer So Its Story Survives Due Diligence. The technology section is where that story is easiest to check.

A checklist before the document goes out

For the founder, the technical lead and the banker, together, before a teaser or memorandum reaches a buyer:

• Every technology sentence has a named file in the data room, or a named person who can show it in the system.
• Adjectives are replaced by facts: no "scalable", "secure" or "proprietary" without the numbers or the list behind them.
• Every number has a period, a method and a source: uptime, hosting cost, team size, customers, releases.
• Team size separates employees from contractors and states where they work.
• Third-party services, licensed components and AI model providers are named, not hidden behind "our platform".
• Known technical debt is listed with a plan, rather than denied.
• Certifications and audits are stated by exact type, period and scope; nothing is called "ready" without saying ready for what.
• Security and incident statements have been read by counsel, along with the rest of the technology section.
• The deck, the memorandum, the management presentation and the data room use the same numbers from one fact sheet.
• Someone who did not write the section has read it as a reviewer would and listed what they would ask for.
• Gaps that cannot be closed before launch are disclosed in plain words, with what has been done about them.

The last two items are the hardest to do from inside the company. A builder reads "fully documented" and thinks of the documents that exist; a reviewer thinks of the ones that are missing.

What to do next

We do not write sale documents and we are not bankers or brokers. What we can provide is the evidence a document should be written from, checked by the same method a buyer's reviewer will use across the six layers.

If a sale is six to eighteen months away, exit readiness gives you time to turn weak claims into true ones: move accounts, sign missing assignments, measure uptime properly, run a restore, start an audit. It ends with a data room technical section and a mock review. If you are going to market sooner, a vendor due diligence produces a seller report and a buyer report from one review, so the technology section of the memorandum can rest on findings a buyer can read for themselves. If you are on the buy side and want the claims in a memorandum tested early, a red-flag memo reads them against the systems. Each is quoted at a fixed fee agreed in writing before we start, with no success fee. More on scope and access in our FAQ.

Questions