The words of a software deal.

A company bought to join a platform business that a buyer, usually a private equity fund, already owns. The technical review compares the target with the platform's stack: overlapping systems, duplicate billing or customer databases, vendor commitments that outlive the plan, and which product survives. In a buy-and-build program each add-on should be read with one method and one severity scale, so the results line up across companies.

Read Who will buy your software company·See also Platform acquisition, Strategic acquirer

A firm registered to arrange, negotiate or execute securities transactions for others. In an M&A process that work sits with bankers, brokers and licensed advisors, not with a technical reviewer. The Structure is not a broker-dealer: it reads the technology and reports what it finds, and it does not arrange, negotiate or execute transactions or raise capital.

Read About·See also Success fee, Technical due diligence

The purchase of a unit or product line separated from a larger group, or of a company that still runs on systems shared with a parent or sister business. Such a product often depends on the parent's cloud account, login service, licenses, payment account and people. The review first draws the perimeter of the business, then sets out what must be separated before closing, what can run for a time under transition services, and what separation and standalone running will cost.

Read Carve-outs and shared systems·See also Perimeter (carve-out), Transition services agreement (TSA), Separation cost

The sale document a seller's advisor sends to interested buyers after a short teaser, describing the business, its numbers and its technology. A buyer's technical reviewer usually reads it before the repository, and every technology claim in it, such as proprietary, scalable or secure, turns into a request for evidence. Claims the systems confirm become short lines in the report; claims they contradict become findings, so modest and specific wording serves the seller best.

Read Technology claims in a sale document·See also Data room, Vendor due diligence

The secure online folder where a seller shares documents with bidders under confidentiality terms. Its technical section should hold a system overview, an ownership register, IP assignments and a license scan, infrastructure costs, restore evidence, security records, a data map, the team picture and a known issues register. Source code and real personal data stay out: reviewers read code in place through read-only access, and every document should agree with what the systems show.

Read The technical section of the data room·See also Confidential information memorandum (CIM), System overview, Access protocol

The period after a letter of intent during which the seller negotiates with one buyer only. A full technical due diligence normally runs inside it, while the purchase agreement is still open, so findings can still influence price and terms. Exclusivity windows tend to be short, which is why access, the request list and interviews should be agreed in the first days; a review that starts late tends to shrink into a skim.

Read What a technical due diligence reads·See also Letter of intent (LOI), Technical due diligence, Signing and closing

A program, run month by month for at least four months, that prepares a software company for a sale expected in 6 to 18 months. It begins with a baseline review of all six layers, ranks the findings by their effect on price and risk, tracks the fixes with a one-page status for the board, builds the technical section of the data room and ends with a mock review. It prepares the company; it does not run the sale.

Read Exit readiness·See also Technical baseline, Mock review, Vendor due diligence

A dealmaker who finds and negotiates an acquisition first and then raises equity for that single deal, instead of investing from a committed fund. Like a searcher, an independent sponsor often buys a founder-run company with lenders and investors watching and no technical team of its own. The review then asks whether the product keeps running once the founder steps back, and presents its findings in terms lenders and investors can read.

Read Who we serve·See also Search fund, Founder dependency, Red-flag memo

A document in which a buyer sets out the proposed price, structure and main terms of a deal, usually together with a request for exclusivity. Before it is signed there is little or no access to the systems, so technical work is limited to what the company shows publicly, a management call, or a red-flag memo on whatever material is available. Points found at this stage can still be written into the letter itself.

Read Technical checks before buying a small software company·See also Exclusivity, Red-flag memo

The segment of M&A made up of smaller private companies, often led by their founders. Deals here usually have a banker, a lawyer, an accountant and a quality of earnings report, but often nobody whose job is to read the technology, even when the product is the whole business. The Structure focuses on lower middle market software deals in the United States.

Read About·See also Quality of earnings (QoE), Technical due diligence

The first company a private equity fund buys in a market, meant as the base for growth and for later add-on acquisitions. The fund usually buys the team along with the product and writes a 100-day plan soon after closing. Its technical review weighs cost per customer at scale, who stays after closing, and whether the product, infrastructure and team could absorb another company. Findings that slow every future change weigh heavily here.

Read Who will buy your software company·See also Add-on acquisition, Cost per customer, 100-day plan

The binding contract that transfers the company or its assets, with the price, representations and warranties, indemnities, conditions and covenants. Technical findings reach it through counsel: a known cost may move the price, and a bounded issue may be handled by an escrow, a specific indemnity or a condition before closing. The reviewer supplies facts, evidence and cost ranges; the parties and their counsel decide what goes into the agreement.

Read What a technical due diligence reads·See also Points for counsel, Specific indemnity, Condition before closing

An accounting review, usually by an outside firm, that checks whether reported earnings, margins and costs hold up and how each cost is classified. It confirms the history. A technical review asks the next question: whether the system behind those numbers will keep producing them, for example whether credits flatter the hosting bill or people quietly do work the software is said to do. Figures are shared so the two views agree.

Read The technology behind the SaaS numbers·See also Gross margin, Cloud credits, Cost of revenue

A short, risk-led review that looks for the issues able to reprice a software deal, alter its terms or end it. It reads all six layers but goes first where deal-changing problems usually sit, samples where a full review would read everything, and states what it read, sampled and did not examine. It opens with a verdict, and before access exists it can start from public information and the data room.

Read Red-flag memo·See also Verdict (red-flag memo), Technical due diligence, Limits of the review

A vehicle in which a searcher raises money from investors to find, buy and then run one company, often with an SBA-backed or other bank loan. Such targets are usually run by their founders, who also hold most of the technical knowledge. The review therefore checks that accounts belong to the company, that someone has documented how to deploy and recover the product, and what paid engineers or contractors will cost once the founder's hours are gone.

Read Technical checks before buying a small software company·See also Independent sponsor, Founder dependency, Red-flag memo

Signing is when the purchase agreement is executed; closing is when the money moves and ownership passes. Between the two, buyers typically require account moves, missing IP assignments and access removals, and limit major technical changes. In many smaller deals both happen on the same day, so that work moves before signing. A buyer who starts running the target's systems before closing can raise gun-jumping questions, which belong to counsel.

Read From the diligence report to a 100-day plan·See also Condition before closing, Covenant to closing, 100-day plan

A company in the same or a neighboring market that buys another business for its product, customers or people, to strengthen its own operations. Because it brings its own engineering, security team and platform, its review focuses on what combining the two will take: overlap, migration of data and customers, identity and single sign-on, its internal security standards, and open-source obligations once the code ships inside its products.

Read Who will buy your software company·See also Add-on acquisition, Copyleft license

An advisory engagement for owners of IT, software and tech-enabled service companies who are deciding whether to grow, sell or wait. It consists of two private calls with an M&A advisor and a written report on where the company stands, which paths fit, the likely buyers, market ranges for similar companies with sources, and next steps. It is not a valuation, a sale process, or legal, tax or investment advice.

Read Strategic options review·See also Success fee, Lower middle market

A fee paid only if a transaction closes, often calculated on the deal value. It is common and legitimate for sell-side advisors, whose job is to get a deal done, and owners should ask how any advisor is paid. For a reviewer it would create a reason to soften findings, so The Structure works for one fixed fee agreed in writing before the work starts, the same whether the deal closes, changes price or falls apart.

Read Before you hire an M&A advisor·See also Engagement letter, Broker-dealer

An independent examination of a software company's technology ahead of a purchase or sale, most often for a buyer inside exclusivity. It reads six layers: ownership and IP, infrastructure and cost, data and privacy, code and architecture, security and access, team and knowledge. Each finding carries a severity, evidence, business impact and a cost and time to fix. The aim is not a grade for the code but a clear view of what could change the deal and what the technology will cost to own.

Read Technical due diligence·See also Finding, Red-flag memo, Vendor due diligence

An agreement under which the seller keeps providing agreed services to a sold business for a fixed period after closing, for example hosting, a shared login, payment processing or security monitoring. Counsel and the deal team draft and price it. The technical review lists each service it must cover, how to tell it is working, when the buyer can realistically leave it, and what exit help the seller owes.

Read Carve-outs and shared systems·See also Carve-out, Perimeter (carve-out), Standalone running cost

An independent technical review paid for by the seller ahead of a sale process and conducted as a buyer's own review would be. One review produces two reports: a seller report with the full findings and advice, and a buyer report written for the data room. The seller may correct errors of fact but not ratings or findings. Buyers usually still run a shorter confirmatory review that tests its key claims, while Q&A support answers their technical questions.

Read Vendor due diligence·See also Buyer report, Seller report, Exit readiness

The account under which a mobile app is published, holding its listing, reviews, signing setup and update path. When it is enrolled to an individual, a departed co-founder or a contractor instead of the company, the app in effect belongs to a person. Each store has its own transfer rules and conditions, so moving the account or listing into the company's name should start early, often at signing.

Read Ownership gaps that stop a software deal·See also Control and transferability, Cloud root account

A deal structure in which the buyer acquires specific assets and contracts instead of the company itself. Each repository, account, domain, license and contract must then be transferred individually, and any contract that bars assignment needs the counterparty's consent. Counsel decides what the documents require; the technical review supplies the list of assets the product depends on and who holds each one today.

Read Ownership gaps that stop a software deal·See also Stock purchase, Change-of-control clause

A contract term that lets the other party end, reprice or approve a contract when the company is sold or its control changes. Software licenses, vendor agreements, API contracts and some customer contracts carry them. The reviewer lists the contracts the product relies on and flags these terms; whether consent is needed and how to get it is a question for counsel, often settled before closing.

Read Ownership gaps that stop a software deal·See also Asset purchase, Stock purchase

The top-level owner account at a cloud provider, which controls every resource, user and bill beneath it. A reviewer checks its registered entity, contact email, payment method, recovery options and who holds the root credentials and MFA. A production account registered to a former contractor, or recoverable only through someone who has left, is rated Critical until it is moved into the company's name.

Read Our approach·See also Control and transferability, Critical finding, Multi-factor authentication (MFA)

The two parts of ownership in a software deal. Control asks whether the company itself, rather than a founder, contractor or vendor, holds each account, right and contract now; transferability asks whether that hold can move to the buyer. A gap in either is a gap in what the price assumes. Reviewers confirm control in the account settings, because a seller's word is a starting point, not evidence.

Read Ownership gaps that stop a software deal·See also IP assignment, Cloud root account, Evidence

An open-source license, such as the GPL or the AGPL, that requires software built with the licensed code to be shared on the same terms when certain conditions are met. Whether a duty arises depends on how the product reaches customers: software they install can trigger different obligations from software they only use online. The reviewer maps each copyleft component and how it is used, and counsel decides what applies.

Read What a technical due diligence reads·See also GNU Affero General Public License (AGPL), Open-source license inventory, Software bill of materials (SBOM)

The registrar account holds a company's domain names, and DNS settings point those names at its website, application and email. If a former agency, an employee or the founder is the registrant, the company does not control the address its customers use. Reviewers check the registrant record, expiry dates and who can change DNS. Some registrars block transfers for a while after owner details are edited, so moves should start early.

Read Ownership gaps that stop a software deal·See also Control and transferability, App store developer account

A copyleft open-source license whose duty to share source code can apply when software is offered to users over a network, not only when it is distributed. An AGPL component inside a hosted product is therefore a common ownership finding. Its weight depends on how the component is used: often the fix is replacing one component, and sometimes counsel finds no obligation at all. The reviewer gives counsel the facts either way.

Read Our approach·See also Copyleft license, Open-source license inventory

A signed written transfer of rights in work, such as code, from an employee, contractor or agency to the company. Paying an invoice does not by itself transfer ownership, so a reviewer matches every author in the commit history against signed agreements, looking hardest at the earliest contributors. Most gaps close with a confirmatory assignment before closing; a gap from someone who wrote core code and will not sign is far more serious. Counsel drafts the documents.

Read Ownership gaps that stop a software deal·See also Commit history, Control and transferability, Condition before closing

A list of the open-source components in a product with the license of each, usually produced by scanning the dependencies and, ideally, the code itself. Copyleft licenses are flagged with a note on how each component is used: linked, modified, distributed or served over a network. Tool output is evidence, not a finding: a person reads the actual use, and counsel decides what any obligation means.

Read The technical section of the data room·See also Software bill of materials (SBOM), Copyleft license, Dependency

The map of everything a carved-out product needs to run, with each item marked by who owns it today and who will own it after closing. Items fall into three groups: dedicated to the business, shared but separable with known work, or shared and entangled so that separating them is a project of its own. It is built outward from what customers touch, and splitting customer data is usually the hardest part.

Read Carve-outs and shared systems·See also Carve-out, Transition services agreement (TSA), Separation cost

A structured list of every component a piece of software contains, with versions and licenses. In a deal it answers two questions at once: what open source asks of the company, and which components carry known vulnerabilities or are past their support dates. A current SBOM or license scan in the data room saves review time, although declared packages alone can miss code copied straight into the repository.

Read The technical section of the data room·See also Open-source license inventory, Dependency, Known vulnerability

A deal structure in which the buyer acquires the shares of the company. The company itself changes hands, so the same legal entity keeps its own accounts and contracts, apart from any that change-of-control clauses affect. It does not move assets held outside the company: repositories, cloud accounts or domains in a founder's, employee's or agency's name still have to be transferred to the company before closing.

Read Ownership gaps that stop a software deal·See also Asset purchase, Change-of-control clause

An agreement with a cloud or software provider that lowers prices in return for committed usage or spend, such as savings plans, reserved capacity or a minimum annual amount. It is often sensible, but it can outlive the deal and bind the buyer to a provider it meant to leave. The reviewer records the amount, the term and what the bill would look like without it.

Read The technology behind the SaaS numbers·See also Cloud credits, Cost of revenue

Free usage granted by a cloud or AI provider, often through startup programs, that may pay for much of the bill for a time and then end. Margins earned on credits can vanish when they expire, and moving accounts to a new owner can end some programs early. Credits that cover most of the bill and expire soon after closing are often rated High.

Read The technology behind the SaaS numbers·See also Gross margin, Cloud commitment, High finding

The costs of delivering the product to customers, which in a SaaS company usually include hosting, third-party services the product calls, support and the engineering time spent keeping production running. How each line is classified is for the accountants. The reviewer maps every paid service to its purpose and payer so they see every line, including production costs booked as development or paid on a founder's personal card.

Read The technology behind the SaaS numbers·See also Gross margin, Quality of earnings (QoE), Inference cost

What it costs to serve one customer, built from what the system records rather than from an average of the bill. Where cloud resources carry cost allocation tags the work is direct; otherwise it is estimated from requests, storage and compute per tenant, with the assumptions stated. The spread matters more than the average, because a few heavy customers on flat pricing can carry or sink the margin of the whole base.

Read The technology behind the SaaS numbers·See also Step cost, Gross margin, Single-tenant deployment

Revenue minus cost of revenue, as a share of revenue; in software it is much of what a buyer pays a multiple for. A technical review does not restate it. It reports the facts that move it: costs outside cost of revenue, credits and commitments with end dates, inference costs, manual work behind product features, the cost curve at the planned size and costs that start after closing.

Read The technology behind the SaaS numbers·See also Cost of revenue, Cloud credits, Quality of earnings (QoE)

What a product pays an AI model provider, or its own hardware, each time a model answers a request. Unlike most SaaS costs it can rise with use: heavier users cost more, and a flat subscription can hide customers who lose money every month. A reviewer asks for inference cost by month, per customer, per feature and per plan, and works through what a provider price change would do to the margin.

Read AI diligence: product or wrapper?·See also AI wrapper, Gross margin, Cost of revenue

The practice of defining servers, networks and cloud settings in versioned files that can rebuild an environment, instead of configuring them by hand in a console. It matters in a deal because hand-built infrastructure is hard to reproduce, test, hand over or recover. A production account with no record of how it was built is a typical finding; infrastructure already in code is a strength the plan can rely on.

Read Our approach·See also Restore test, Runbook, Strength

Tools that watch a production system for errors, slowdowns, failed jobs and outages and notify someone when they happen. Reviewers check what is watched, who gets called and whether incidents were caught by the system before customers reported them. An alert that lands in a mailbox nobody reads does not count, and confirming that alerts reach a named person is among the first tasks after closing.

Read What a well-built product looks like·See also Incident log, On-call rotation, 100-day plan

Restoring a backup into a separate environment to prove the data can actually be recovered, and timing how long it takes. Nightly backups that have never been restored are among the most common findings and are usually rated High, because nobody knows whether the data is safe. The evidence of a fix is a dated restore log with the time taken and a check of the restored data.

Read Our approach·See also Runbook, High finding, Evidence

The one-time cost of moving a carved-out business off its parent's systems: setting up its own accounts, extracting its data, replacing the shared login and merchant account, rebuilding pipelines and integrations, testing, and staffing all of it. It is estimated like any fix, in engineer weeks and as a range with stated assumptions, and kept apart from the ongoing standalone running cost so that neither is counted twice.

Read Carve-outs and shared systems·See also Standalone running cost, Carve-out, Cost to fix

Contract terms that promise customers a level of availability or response, often with service credits when the promise is missed. A figure such as 99.9% sounds exact, so it is checked exactly: how it is measured, for which components, over what period, with what excluded, and against the incident log and any credits paid. At 99.9%, a 30-day month leaves room for about 43 minutes of downtime.

Read Technology claims in a sale document·See also Incident log, Monitoring and alerting

A setup in which a customer runs on its own servers, database or copy of the product instead of a shared one. Some regulated customers insist on it, and automation with a single shared codebase can make it efficient. It turns into a finding when deployments drift onto their own versions or code, every upgrade becomes a manual project, and the effort hides outside cost of revenue.

Read The technology behind the SaaS numbers·See also Cost per customer, Cost of revenue

The yearly cost of operating a carved-out product as an independent business: cloud at list prices with no group discount, licenses at a smaller company's rates, and the monitoring, security tooling and people the parent used to supply. It often differs from the allocated costs in the carve-out financials. The review states it as a range with assumptions; how it bears on price is for the deal team.

Read Carve-outs and shared systems·See also Separation cost, Carve-out, Transition services agreement (TSA)

A cost that stays flat as a business grows and then jumps, such as a larger database tier, a second region for one customer, a dedicated cluster or an added night support shift. A reviewer splits running costs into fixed, variable and step costs, because the steps decide whether the margin in a growth plan holds. Where the system cannot reach the planned size without work, that work is costed as a finding.

Read The technology behind the SaaS numbers·See also Cost per customer, Gross margin

A record of every system holding personal data, listing the kinds of data in each, where it is hosted, who has access, how long it is kept and which outside services receive it, with backups, logs and analytics tools included. The reviewer compares it with the privacy policy and customer contracts; whether a gap breaks a law is for counsel. A good data map in the data room needs no real personal data at all.

Read Our approach·See also Personal data, Subprocessor, Privacy policy

Replacing names, emails and other personal fields in a copy of data with realistic but fictitious values, so the copy can be used for testing or review without exposing real people. Unmasked production data on a test server or a developer laptop is a common finding, usually cheap to fix, and it matters since test machines seldom get production-grade protection. Reviewers themselves work from data in place or masked samples.

Read Our approach·See also Personal data, Access protocol

A contract between a company and a vendor that handles personal data on its behalf, setting out what the vendor may do with the data, how it protects it and what happens at the end of the relationship. When a vendor holds personal data with no such agreement, the fix is usually the missing contract and a check of what data the vendor received, handled by counsel and then filed in the data room.

Read Our approach·See also Subprocessor, Data map

Where data is physically stored and processed, and any promise or rule that limits it to a country or region. A common finding is a customer contract or privacy notice that promises data stays in the United States while requests go to a vendor or AI provider that processes them elsewhere. Reviewers compare provider settings with the promises made; what a mismatch means legally is for counsel.

Read AI diligence: product or wrapper?·See also Subprocessor, Privacy policy

How long each kind of data is kept, and whether deletion really happens when the policy says it does. Reviewers check retention across the main database, backups, logs and analytics tools, because data kept forever adds cost and exposure for as long as the company exists. Setting retention is a standard step in preparing for a sale, alongside mapping personal data and masking test copies.

Read Exit readiness·See also Privacy policy, Data map

A company's legal right to use data for a given purpose, such as training, tuning or building retrieval for an AI feature. Proprietary data is a strong claim and the one most in need of proof: its source, the license or contract clause behind it, how it was labeled and how it is kept current. Data scraped, licensed for another use or collected from customers with no clear contract term can make a supposed asset a liability.

Read AI diligence: product or wrapper?·See also AI wrapper, Personal data

The parts of a system that store, process or transmit card numbers and therefore fall under card industry security standards (PCI DSS), which expect timely patching among other controls. A checkout that handles card data directly widens that scope; hosted payment fields or a redirect to the payment provider narrow it. Reviewers check whether card data ever touches the company's own servers, and moving it out of scope can be a condition before closing.

Read An aging platform in an acquisition·See also Sensitive data, Known vulnerability

Information that identifies or relates to a person, such as names, emails, addresses, payment details or usage records. Because customer data is what most often draws regulators, contract disputes or insurer questions after a deal, a reviewer maps where it is collected and stored and who can reach it. It is never copied in a review: it is viewed in place with the company's team or as masked samples.

Read Our approach·See also Data map, Data masking, Sensitive data

The public statement of what personal data a company collects, why, who receives it and how long it is kept. A reviewer compares it with what the system actually does: a policy that promises deletion the system cannot perform, or a marketing tool that receives more data than disclosed, is a finding. Privacy promises usually stay with the product after a sale, and whether a gap breaks a law is for counsel.

Read Our approach·See also Data map, Data retention, Subprocessor

Categories of personal data that carry stricter rules, such as health records, children's data or payment card data. A reviewer flags where such data appears and asks for the relevant policies and evidence of controls instead of the data itself, while counsel confirms which rules apply. Products in regulated areas may also need a specialist for part of the review, which a careful proposal states at the outset.

Read FAQ·See also Personal data, Payment card data scope

A third-party service that receives personal data from a company in order to work on its behalf, such as hosting, email delivery, analytics, support tools or an AI model provider. Many companies publish a subprocessor list. Reviewers compare that list with what the product really sends where and check that an agreement covers each one; a list that names vendors no longer used, or misses current ones, is a signal.

Read The technical section of the data room·See also Data processing agreement (DPA), Data map

Fake orders, leads, users or payments created while testing a live system and left in its data. They inflate the revenue reports, sales pipelines and active-user counts a buyer may rely on. A careful migration or release plan says how it tests without creating them, for example with requests the system must refuse. A reviewer asks how testing is done and samples the data for leftovers.

Read What a migration changes·See also Personal data, Cutover

A product whose AI feature is little more than a call to a third-party model with an instruction, with no data, workflow, quality measurement or switching path of its own. A wrapper can still be a good business with strong distribution and healthy margins; the risk is pricing it as if its AI were a moat. The review looks at where the value sits, what the model dependency costs and what a switch would take.

Read AI diligence: product or wrapper?·See also Evaluation set, Inference cost, Data rights

Code written largely by AI coding tools instead of typed by engineers. Its origin is never a finding on its own: a capable team that checks each change, tests the paths that matter and can explain its system is not riskier because a tool typed some of it. What matters is code no person understood or verified, which reviewers look for in commit and review history, tests on money paths, security patterns and walkthroughs. Ownership questions go to counsel.

Read A product written largely with AI·See also Code review, Walkthrough interview, Authorization check

Code that checks the product's behavior automatically, ideally on every change. Coverage percentages are weak evidence: reviewers read the tests on the paths that carry money and access, such as billing, permissions and integrations, and may ask to see one fail when the rule it guards changes. No tests around billing is typically a Medium finding, and missing tests raise the cost of every other fix.

Read What a well-built product looks like·See also Deployment pipeline (CI/CD), Parity test, Medium finding

A second person reading a change before it reaches production, usually through pull requests and branch protection rules. Reviewers check whether the history shows real review or changes merged by their own author within seconds. Missing review matters more where much of the code was generated, and agent instruction files, hooks and the scripts they call should be reviewed like any other code, with a named owner.

Read A product written largely with AI·See also AI-generated code, Instruction file, Deployment pipeline (CI/CD)

The moment a live system is switched from an old platform or setup to a new one. Reviewers ask what happened at the last cutover: whether it was scripted, how long it took, what failed, whether a tested rollback existed before the switch, and whether the old system is still there to go back to. If a team cannot say how long the last switch was degraded, it probably never measured.

Read What a migration changes·See also Rollback, Replatforming, Parity test

An outside package, library or service that a product's code relies on. Each one is code the buyer now owns, with its own vulnerabilities, license terms and support dates. Reviewers read the manifests and lock files for age, abandoned packages, known vulnerabilities and overlaps; products assembled quickly tend to carry more than they need. Regular small updates in the history are a sign of good hygiene.

Read What a well-built product looks like·See also Software bill of materials (SBOM), Known vulnerability, End of support

The automated path a change takes from a developer's commit through build, tests and review to production, and back out when needed. Reviewers read its configuration and release history: how often releases go out, how many people can deploy, whether there is a staging step and whether rollbacks have been used. A deploy that runs only from one person's laptop is both an infrastructure finding and a key-person finding.

Read What a well-built product looks like·See also Rollback, Automated tests, Key-person risk

The date after which the maintainers of a framework, runtime, platform version or operating system stop fixing it. Most publish at least two dates: one when bug fixes stop and a later one when security fixes stop, sometimes followed by paid extended support. A framework past its end of security support is usually rated High, because new vulnerabilities go unpatched and the upgrade takes weeks or months.

Read An aging platform in an acquisition·See also Technical debt, Known vulnerability, High finding

A fixed collection of real cases with expected results, used to score an AI feature on every release and whenever a model, prompt or provider changes. Without one, a team cannot tell whether a change made the answers worse, which turns a provider switch into a project of months instead of weeks. Reviewers ask to see recent score reports; versioned prompts tied to test results point to a real product.

Read AI diligence: product or wrapper?·See also AI wrapper, Automated tests

Changes made directly to a platform's own files instead of through its extension points, common in older e-commerce stores. Each patch or upgrade then needs those edits merged back by hand, which is often why patching quietly stopped. Reviewers compare the installed core with a clean copy of the same version, count the overrides, and list third-party extensions with their vendors and compatible versions.

Read An aging platform in an acquisition·See also End of support, Replatforming, Technical debt

A test or comparison showing that a rewritten or migrated system behaves like the old one where it matters, often run over historical data such as past invoices. Rewrites change behavior nobody chose to change, such as how numbers round or dates print, because those answers came from the old language's defaults. A written list of what had to stay the same, with the last clean comparison, is evidence a buyer can read.

Read What a migration changes·See also Replatforming, Cutover, Automated tests

Moving a product to a different platform, framework or language, for example from an aging commerce platform to a hosted one or to a custom build. It is usually measured in quarters, and its cost range is the widest of any route, because undocumented business rules and data cleanup are where estimates fail. Risks include checkout errors, customer accounts that do not move cleanly and lost search traffic from missing redirects.

Read An aging platform in an acquisition·See also Rewrite, Parity test, Cutover

Rebuilding a product from scratch instead of improving it in steps. Reviewers rarely recommend it in a deal: the new system must recreate years of unwritten rules and integrations while the old one stays live, the bill is hard to cap and nothing new ships for months. Begun just before a sale, a rewrite usually looks riskier to a buyer than a dated but stable system with a priced plan.

Read How technical debt is put into a deal·See also Technical debt, Replatforming, Fix plan

Undoing a release or a switch and returning to the previous working version. Reviewers check whether a rollback path exists, whether it was built before the change instead of improvised after it, and whether it has actually been used through the normal process. A plan that amounts to restoring a backup is, in practice, untested, which is why a scripted way back counts as evidence.

Read What a migration changes·See also Cutover, Deployment pipeline (CI/CD), Restore test

The extra effort every change to a system costs because of earlier shortcuts and decisions, many of them sensible at the time. Almost every product has some, so saying a codebase has debt tells a buyer little. A usable debt finding names the part of the system, the evidence, the business impact and a cost range with assumptions, while matters of engineering taste stay out. Sellers can keep a short debt register with a plan.

Read How technical debt is put into a deal·See also Cost to fix, Rewrite, End of support

The rules a reviewer follows when reading a company's systems. At The Structure an NDA comes before the first document; access is read-only through named accounts the company creates for the period of the review; personal data is never copied; everything received is listed in the report; and at the end access is closed with written confirmation of what is kept. There are no writes to production and no penetration test without written consent.

Read Our approach·See also Named account, Data masking, Penetration test

Permissions that let a person change settings, users, data or billing in a system such as the cloud console, code host, identity provider, DNS or payment processor. Reviewers read the admin lists across these systems and ask whether anyone reviews them. Rights concentrated in one person are quick to fix when they sit under company accounts; admin rights held through a personal account are also an ownership finding.

Read Key-person risk in the technology·See also Offboarding, Multi-factor authentication (MFA), Key-person risk

An AI assistant that works inside a codebase on its own: reading the repository, running terminal commands, installing packages, editing many files and, where permitted, reaching servers and cloud consoles. Agents are users with real access that often appear on no access list. A reviewer asks which agents are in use, on whose accounts, what they can reach and run without approval, and where their credentials come from.

Read AI coding agents inside a company·See also Prompt injection, Instruction file, Secrets in code

The rule that decides whether a given user may see or change a given record. It has to be enforced on the server and in the database, not only by hiding buttons in the interface. A pattern common in hastily generated products is a check that holds in a demo and fails against a direct request, or database access rules left switched off. Customer records readable without authorization are rated Critical whoever wrote the query.

Read A product written largely with AI·See also AI-generated code, Critical finding, Known vulnerability

The record of outages, security events and data problems: what happened, how it was found, how long it lasted, who was affected and what changed afterward. Reviewers read it alongside postmortems and monitoring. A claim of no incidents needs the logging that would have caught one, and an incident fixed but never written down is itself a finding. Insurance underwriters and buyers both ask about incident history.

Read Our approach·See also Monitoring and alerting, Representations and warranties insurance (RWI), Service level agreement (SLA)

A file in a repository, such as CLAUDE.md, AGENTS.md or an editor rules file, that AI coding agents read automatically at the start of a session to learn project conventions. Because agents give these files weight, they are a place to plant hidden instructions, alongside hooks that run commands and connected tool servers. Text telling the agent not to read a script, to hide its output or not to ask the user first is a red flag.

Read AI coding agents inside a company·See also Prompt injection, AI coding agent, Code review

A published security weakness in a specific version of an application, library, platform or runtime. Reviewers scan dependencies and code for them, check whether the latest security release for each version line is actually installed and ask how patches are tested. A version still in support but several patches behind is unpatched in practice; evidence of a vulnerability exploited in the wild, or signs of compromise, can be Critical.

Read An aging platform in an acquisition·See also Dependency, End of support, Penetration test

Sign-in that requires a second proof beyond a password, such as an app code or a hardware key. Reviewers check that it is switched on for every admin account in email, code hosting, cloud, payment and admin tools, and insurance underwriters ask about it among their first cybersecurity questions. A report showing MFA on all admin accounts is typical evidence of a fix in the first 30 days after closing.

Read Our approach·See also Admin rights, Named account, Offboarding

A login that belongs to one identifiable person, as opposed to a shared login used by a whole team or an agency. One shared admin password, sometimes still known to people who left, is a common finding, because nobody can tell who did what or remove one person's access. Reviewers themselves work only through named, read-only accounts created by the company for the period of the review.

Read FAQ·See also Access protocol, Admin rights, Offboarding

Removing a departing employee's, contractor's or agency's accounts, keys and access when they leave, and rotating any shared credentials they could have seen. Former staff who still have production access is cheap to fix and serious until it is fixed. Reviewers compare offboarding records with the current access lists and look for a written routine, not a favor someone happens to remember.

Read Our approach·See also Admin rights, Named account, Condition before closing

A sanctioned exercise in which testers try to break into a company's systems to find weaknesses an attacker could use, as of a given date. Technical due diligence is not one: its access is read-only and it attacks nothing. Reviewers read any existing test reports and check whether their findings were closed. If a test is needed before closing, it requires the company's written consent and is commissioned separately.

Read FAQ·See also SOC 2 report, Known vulnerability, Access protocol

Instructions hidden in content an AI model reads, such as a repository file, an issue, a web page, an email or a tool's output, that try to make it act for someone other than its user. Inside a coding agent, a planted instruction can become a real command on a machine holding credentials, rather than a bad chat reply. It also matters for products that feed customer documents to a model or let a model act on customer systems.

Read AI coding agents inside a company·See also Instruction file, AI coding agent

Passwords, API keys, tokens or connection strings stored in source files, configuration or the repository history, sometimes even in code that runs in the browser. Deleting them from the current files is not enough: they must be rotated, and the logs read to see whether anyone used them. Reviewers scan the full history and built bundles, and the evidence of a fix is a rotation log listing secrets by name, never by value.

Read Our approach·See also Offboarding, AI coding agent, Known vulnerability

A report in which an independent CPA firm attests to how a company's controls meet the Trust Services Criteria. Type 1 looks at control design on a single date; Type 2 at whether the controls worked over a period. It is useful evidence but is silent on code ownership, how easily the product can change and what it costs to run. Reviewers read its scope and period, and SOC 2 ready is not a report type.

Read Technology claims in a sale document·See also Penetration test, Evidence

The number of people who would have to become unavailable before a critical part of the system could no longer be understood, changed or recovered. A bus factor of one on billing, deployment or a core integration is the classic form of key-person risk. Reviewers estimate it area by area from commit history, release rights, incident records and interviews, not from the org chart.

Read Our approach·See also Key-person risk, Commit history, Knowledge map

The record in a code repository of who changed what and when. Reviewers use it to match every author with a signed IP assignment and to see where one name dominates a critical area such as billing or sign-in. It needs care: squash merges, pair programming, shared agency accounts and old email aliases distort who appears to have done the work, so interviews and access lists confirm what it suggests.

Read Key-person risk in the technology·See also IP assignment, Bus factor, Walkthrough interview

Reliance on outside freelancers or agencies to build or run the product. It is fine in itself, and many good products were built by outside teams. It becomes a finding when a contract can end on short notice, the IP terms are unclear, the agency still holds the repository or the hosting, or one long-time contractor holds the only knowledge of a core integration or the only way to deploy.

Read FAQ·See also Key-person risk, IP assignment, Control and transferability

The degree to which a company's technology rests on its founder: the founder-CTO who wrote most of the core, approves every release, holds the root credentials or answers every hard question. It weighs most for a buyer who expects the founder to step back after closing, as a searcher usually does. The honest test is what actually happened the last time the founder was away for weeks.

Read Key-person risk in the technology·See also Key-person risk, Search fund, Handover rehearsal

A test in which the person everyone relies on takes a break of a week or two, or a newcomer sets up and deploys the system from the documents alone, while the team writes down what broke or had to be asked. It is the most honest evidence that knowledge has moved, and the step most often skipped. Each question it raises becomes a page of documentation to write.

Read Key-person risk in the technology·See also Runbook, Key-person risk, Founder dependency

The risk that only one or two people can understand, change, release or recover a critical part of the system, and that the company has never tested doing it without them. Reviewers find it across commit history, admin and release rights, incident records and interviews. It is mostly rated High or Medium, depending on what would stop if the person left and whether the company can fix it without that person's goodwill.

Read Key-person risk in the technology·See also Bus factor, Founder dependency, Retention agreement

A record of who understands each critical area of a system, such as billing, sign-in, deployment, recovery and each external integration, and where that knowledge is written down. Sellers prepare one so a buyer can see that no area depends on one person alone. In the technical section of the data room it sits beside the team chart with roles and employment type.

Read Who will buy your software company·See also Bus factor, Runbook, Data room

The schedule of who answers when production fails outside working hours. Reviewers look past the wiki to the paging tool and the incident history, because a schedule means little when one person closed every incident last year. A product supported by a single person on call, often the founder at night, needs a real rotation once that person steps back, and that rotation has a cost.

Read Key-person risk in the technology·See also Monitoring and alerting, Key-person risk, Incident log

An arrangement, such as a stay bonus paid in parts, that keeps a key engineer or founder in place for a period after closing. It buys time with the person, not a transfer of what they know. Deal teams often pair it with handover milestones that can be checked, sometimes tied to deferred payment or an earn-out, such as a second engineer releasing to production. The terms are for counsel.

Read Key-person risk in the technology·See also Key-person risk, Handover rehearsal

A short written procedure for an operational task, such as deploying, rolling back, restoring a backup, renewing a certificate or handling a recurring incident. It counts as evidence when it is dated, owned and recently followed by someone other than its author. A single page that someone used last month is worth more than a long wiki nobody reads, and a deployment that lives only in one engineer's head is a common finding.

Read Key-person risk in the technology·See also Handover rehearsal, Restore test, Knowledge map

A short document, usually two to four pages with a diagram, that lets a stranger understand a product: what the product does, its main parts, the languages and frameworks it uses with their versions, the outside services it relies on and the path a change takes to production. It frames everything else a reviewer reads, so it must match the cloud console and the invoices, and it should carry a date and its author's name.

Read The technical section of the data room·See also Data room, Knowledge map

What a team knows about its system that is written down nowhere: the monthly manual step, the field mappings of an integration, the scheduled job on a server only one person can reach, the reason behind an odd design. It gathers around integrations and old modules, and in AI-built products it may sit in chat sessions nobody kept. Unless it is recorded, it leaves with the people who hold it.

Read Key-person risk in the technology·See also Runbook, Key-person risk, Knowledge map

A conversation in which engineers show a reviewer, on screen, how part of the system works instead of describing it: a release, a restore, the billing logic. Interviews are scheduled through the seller and only with its consent, usually three to five of them, and staff are never asked about the deal. A team that can explain why a module is built the way it is tells the reviewer something documents cannot.

Read Technical due diligence·See also Key-person risk, Commit history, AI-generated code

The new owner's plan for the first months after closing: who does what, by when and with what budget. A good diligence report is its first draft, because the fix plan already groups findings by time window with cost ranges and assumptions. The buyer adds owners, dates and the integration choice, starting with control and recovery in the first 30 days and with High findings planned and started within the 100 days.

Read From the diligence report to a 100-day plan·See also Fix plan, High finding, Findings register

The version of a vendor due diligence report written to be shared with bidders in the data room under the usual confidentiality terms. It explains the system, sets out each finding with its rating and evidence, notes what has been fixed since the review and gives the plan for the rest. It carries the same facts as the seller report, just fewer of them, and never contradicts it. Reliance by a buyer or its lender is agreed in writing.

Read Vendor due diligence·See also Seller report, Vendor due diligence, Reliance

Something the seller must do before the money moves, written into the purchase agreement by counsel. Technical examples include moving domains, cloud and code accounts into the company's name, collecting missing IP assignments and removing former staff access. Because these are facts that can be checked, they suit closing conditions well, and buyers ask to see each move done, not promised.

Read Technical due diligence·See also Covenant to closing, Critical finding, Signing and closing

The estimated money and calendar time needed to resolve a finding, always given as a range with its assumptions: the team assumed, the starting state of the system, the conditions behind the low figure and what drives the high one. It is written for any competent team, so a buyer can get a second quote. Costs that cannot be priced honestly, such as fines or incidents that have not happened, are left out.

Read Our approach·See also Engineer week, Finding, Fix plan

A promise about how the seller runs the business between signing and closing. On the technical side it usually limits major releases, new vendor contracts, access changes or the start of a migration without the buyer's consent. It fits risks that come from change during that window rather than from the system as it stands today. Its wording is a matter for counsel.

Read Technical due diligence·See also Condition before closing, Signing and closing

The highest level on the four-level severity scale: a finding that can stop the deal or should be resolved before closing, for example when the company does not control its own code or its production cloud account. A Critical finding is passed to the client as soon as it is confirmed, not held for the final report. It can still be cheap to fix, since severity and cost are separate measures.

Read Our approach·See also High finding, Condition before closing, Cost to fix

The written contract that starts a client relationship and sets the terms of a review: scope, exclusions, report date, the fixed fee, who may receive and rely on the report, what happens if the deal stops midway and what is kept afterward. Nothing starts until it is agreed. If the scope has to grow, for example to a product nobody mentioned, the change is agreed in writing first.

Read FAQ·See also Reliance, Success fee, Limits of the review

One engineer's working week, the unit in which the effort to fix a finding is estimated before it is turned into money at market rates for the kind of people the work needs. Calendar time is not engineer weeks divided by headcount: fixes depend on each other, and the team still has to run the product meanwhile. A range in engineer weeks always states who is assumed to do the work.

Read How technical debt is put into a deal·See also Cost to fix, Fix plan

A portion of the purchase price set aside, instead of paid at closing, until a named issue is settled or enough time passes without it appearing. It tends to fit a bounded technical issue that is not yet resolved, such as a license conflict being replaced or a restore test still pending. Counsel structures it, and the same cost should not be both deducted from the price and held in escrow.

Read What a technical due diligence reads·See also Specific indemnity, Points for counsel, Purchase agreement

What a finding stands on: an artifact a person on the review team has seen, such as a console setting, a file and line, an invoice, a contract clause or a dated interview statement. A seller's statement is a lead, and tool or AI output becomes evidence only after a person checks it. Each finding says whether it came from the systems, from documents or from interviews, so its weight is clear.

Read AI tools in technical due diligence·See also Finding, Limits of the review, Access protocol

One issue identified in a review, written so it can stand on its own in a board paper or fix plan. It has a title that states a fact, the layer, a severity, evidence with a reference, the business impact in plain words, a cost and time to fix with assumptions, and a recommendation. If the seller's team disagrees, the evidence is checked again; if the view still differs, both are shown and the severity stays the reviewer's.

Read Our approach·See also Evidence, Cost to fix, Findings register

The list of every finding in a report with its layer, severity, evidence, business impact and cost and time to fix. Counsel, the deal team and the new owner's engineers all work from it, and it shows which route each finding has taken, which helps avoid counting one cost twice. Findings keep their numbers, so a later report can be compared line by line with an earlier one.

Read Our approach·See also Finding, Fix plan, 100-day plan

The part of a report that turns findings into ordered work across the first 100 days and the first year after closing, each item with a cost range and the assumptions behind it. It separates what the product needs anyway from what integration will add. The fix is never sold inside the review: the plan is written so any team can act on it, and in an exit readiness program each item gets an owner, a budget and a date.

Read Our approach·See also 100-day plan, Cost to fix, Findings register

The second level on the four-level severity scale: a finding likely to affect price or terms that needs a plan in the first 90 days after closing. Typical examples are a framework past its end of security support, nightly backups that were never restored and one developer holding the only knowledge of billing. Not every High finding closes within 100 days, but each should be planned, budgeted and started.

Read Our approach·See also Critical finding, Medium finding, 100-day plan

The section of a report that states what was read, what was sampled and what could not be seen, with the reason. Insurance underwriters read it closely, because areas not examined tend to be excluded from cover, and a report with big gaps should say so up front. A red-flag memo states its limits so nobody mistakes a fast read for a full one.

Read Red-flag memo·See also Representations and warranties insurance (RWI), Evidence, Red-flag memo

The lowest level on the four-level severity scale: hygiene, best fixed in passing, when engineers are already working in that area. Low findings stay in the register and close in the normal flow of work; turning them into a project usually spends senior time where it changes little. An item of engineering taste with no measurable cost may appear as Low with no cost attached.

Read Our approach·See also Medium finding, Technical debt

The third level on the four-level severity scale: a finding that raises the cost of owning the product and belongs in the first-year plan. Examples include no automated tests around billing or business logic duplicated across a codebase so that every change is slower. A Medium finding can still be expensive to fix, which is why severity and cost are always stated separately.

Read Our approach·See also High finding, Low finding, Fix plan

A review held near the end of an exit readiness program and run the way a buyer's reviewers would run it, with the same method, severity scale and report format. It shows what is left to do before going to market, so the first real review holds fewer surprises, and it becomes the starting point for vendor due diligence, which is then shorter and lighter on the team.

Read Exit readiness·See also Exit readiness, Technical baseline, Vendor due diligence

Findings that touch the purchase agreement or the law, such as missing IP assignments, open-source obligations, privacy gaps or vendor consents, listed for the client's lawyers with the evidence attached. The reviewer states the technical fact and marks it for the right advisor; counsel decides what goes into representations, indemnities or closing conditions. A technical reviewer gives no legal opinion.

Read About·See also Purchase agreement, Specific indemnity, Condition before closing

Formal permission for a party other than the client, such as a lender, investor, insurer or buyer, to rely on a report as if it had been prepared for them, which is different from simply reading it. Reliance is agreed case by case in writing, usually in the engagement letter, so it is best raised at the scoping call. Terms for readers who do not rely on the report are also agreed in writing.

Read Red-flag memo·See also Engagement letter, Buyer report

Insurance that covers losses from breaches of the seller's statements in the purchase agreement. Underwriters ask what diligence was done and how deep it went, especially on cybersecurity controls, past incidents, privacy, IP ownership and open source. Issues known before signing, and areas not examined, are usually excluded, so a known serious finding often needs its own treatment in the agreement. Counsel advises on cover.

Read Technical due diligence·See also Limits of the review, Specific indemnity, Multi-factor authentication (MFA)

The full version of a vendor due diligence report, kept for the seller and the advisors it names. Beyond the findings shared with buyers, it adds advice on which fixes to make before launch, what each costs in money and time, the order to take them in, and how to present what cannot be fixed in time. Both reports come from one review and the same facts, so they never disagree.

Read Vendor due diligence·See also Buyer report, Vendor due diligence

A promise by the seller in the purchase agreement to cover the cost of a particular known issue if it turns into a loss. It tends to fit a known issue with an uncertain cost that general warranties or insurance may exclude, such as a past incident or code from a contractor who cannot be reached to sign an assignment. Whether and how to use it is for the parties and their counsel.

Read What a technical due diligence reads·See also Escrow or holdback, Representations and warranties insurance (RWI), Points for counsel

A fact in a report showing that something works well, written like a finding without a cost to fix: the fact, the layer, the evidence with a reference, what it means for the buyer's plan and its limits. Strengths explain severity ratings, set the starting point for cost estimates and show what the 100-day plan can build on. They never offset a finding.

Read What a well-built product looks like·See also Finding, Evidence

An honest look at the company through the eyes of a buyer's technical reviewers, commissioned by the founder six to eighteen months before a sale, while fixes are still possible. It reads all six layers, rates and costs each finding on the buyer's scale, and turns them into a plan that marks each one fix, disclose or leave, with owners and dates. It opens an exit readiness program.

Read A technical baseline before the banker·See also Exit readiness, Mock review, Fix plan

The view a red-flag memo opens with: go, go with conditions, or stop and look closer. Go means nothing seen should change the price or structure. Go with conditions means specific findings should be fixed before closing, priced or covered in the agreement. Stop and look closer is not advice to walk away; it means something serious should be understood before more money is committed.

Read Red-flag memo·See also Red-flag memo, Critical finding