Questions we hear first.

An independent review of a software company's technology before a transaction. We read six layers: ownership and IP, infrastructure and cost, data and privacy, code and architecture, security and access, and team and knowledge. Each finding gets a severity, the evidence behind it, its business impact and a cost and time to fix. The point is not a grade for the code. It is a clear answer to two questions: what could change the deal, and what will this technology cost to own after closing. See our approach.

Mostly buyers: private equity funds, strategic acquirers, search funds and independent sponsors who need to know what they are taking over. Sellers order the same review before going to market, as vendor due diligence, so they find problems before a buyer does. M&A advisors bring us in to check a client's readiness before a process starts. Lenders and boards rarely order it directly, but they often ask to see it. Who we serve describes each case.

A short red-flag memo fits before the letter of intent or in the first days of exclusivity, when the question is whether to go on at all. A full technical due diligence runs inside exclusivity, before the purchase agreement is final, so findings can still shape price and terms. On the sell side the work starts earlier: exit readiness 6 to 18 months before a sale, vendor due diligence just before the advisor approaches buyers.

Financial due diligence tests the numbers: revenue quality, margins, working capital. Legal due diligence tests contracts, corporate records, litigation and compliance on paper. Technical due diligence tests what the numbers and contracts depend on: whether the company controls its code and accounts, whether the product can be run, changed and scaled at a sensible cost, and who holds the knowledge. The three overlap. A missing IP assignment is both a legal and a technical finding, and a hosting bill that will double is a financial one. We share findings with your counsel and accountants so nothing falls between the reviews.

A penetration test is an authorized attempt to break into systems, run by testers looking for exploitable weaknesses at a point in time. Technical due diligence does not attack anything: our access is read-only. We read security as one of six layers: how access is granted and removed, how secrets are stored, known vulnerabilities in dependencies, incident history and monitoring. If the company has recent penetration test reports, we read them and check whether the findings were fixed. If a test is needed before closing, we say so, and it is commissioned separately.

A SOC 2 report is an attestation by an independent CPA firm on a company's controls against the Trust Services Criteria. A Type 1 report covers how the controls are designed at a date; a Type 2 report covers how they operated over a period. It is useful evidence, but it says little about who owns the code, how hard the product is to change, what the cloud bill will become or who holds the knowledge. We read an existing SOC 2 report as one input. We do not issue SOC 2 reports, and a company does not need one to be reviewed.

A code audit reads the code: structure, quality, tests, dependencies and sometimes licenses. That is one of our six layers, code and architecture. Many deal problems sit outside the code: a cloud account in a former contractor's name, backups nobody has restored, personal data copied to a test server, one developer who alone understands billing. Technical due diligence reads all of it and turns each finding into business impact and a cost to fix. Clean code on a production account the company does not control is still a Critical finding.

Both, at different depths. Before the letter of intent, a red-flag memo on what is available tells you whether there is a deal breaker and which points to write into the letter. After signing, the full review runs inside exclusivity. Exclusivity windows are short, so we agree the request list before access opens, ask for access in the first days and fix the report date in the proposal. Starting late is the most common reason a technical review shrinks into a skim.

Usually four things. Critical findings become conditions to resolve before closing, such as moving a cloud account into the company's name or collecting missing IP assignments. High findings feed the price and terms discussion with your counsel and banker: an escrow, a specific indemnity, a covenant or an adjustment. Medium and Low findings go into the 100-day and first-year plan, with the cost ranges we give. And the report becomes the first brief for whoever runs the technology after closing. See how we rate findings.

Lenders, including on SBA-financed acquisitions, may ask what the buyer knows about the technology the business depends on, especially when the product is the business. Our report is written so a lender can read the summary in minutes and see the evidence behind each rating. If your lender wants to receive the report or rely on it, tell us when we scope the work, so the engagement letter covers who may see it and on what terms. We do not assess the loan or the borrower's credit.

It can. Underwriters of R&W insurance ask what diligence was done, and they ask about cybersecurity, data privacy and IP in particular. A written review across all six layers gives them something specific to read. Keep in mind that issues known before signing are usually excluded from cover, so a serious finding is often better handled through price, a specific indemnity or a fix before closing. Those are decisions for you and your counsel; we give them the facts and the cost of each fix.

The question shifts from whether the product works to what it will cost to bring it in. We look harder at integration: data models and customer identity, systems that overlap with the platform, contracts and licenses that may not transfer, and the people who must stay through the migration. Smaller add-ons often need only a red-flag memo. Across a buy-and-build program we use the same method and severity scale, so findings can be compared from one company to the next.

In a carve-out, the business you buy often runs on systems that belong to the seller: a shared cloud account, a shared ERP or CRM, software licenses in the parent's name, user accounts managed by the parent's IT team. We map what is shared, what must be separated before or after closing, and what a transition services agreement has to cover until it is. Separating the data is often the slowest part and the one most often underestimated. Each item gets a cost and time estimate, so it can be priced into the deal.

A technical review the seller commissions before going to market, run the way a buyer would run it. From one review we write two reports: a seller report with the full findings and what is worth fixing before launch, and a buyer report written to be shared in the data room. During the process we help answer buyers' technical questions. Buyers still do their own checks, but they start from facts rather than a blank page. See vendor due diligence.

A monthly program for founders who plan to sell in 6 to 18 months, running for at least 4 months. It starts with a baseline review of all six layers, then a fix plan ranked by effect on price and risk, monthly tracking with a one-page status for the board, the technical section of the data room built as you go, and a mock review at the end. It makes sense when there is still time to fix things. With only a few months left, vendor due diligence fits better. See exit readiness.

Expect a request list that covers a system overview and how it is hosted; who owns the repositories, cloud accounts, domains and app store listings; signed IP assignments from employees and contractors; open-source components and their licenses; the monthly infrastructure bill; backup and recovery arrangements; security policies, access lists and incident history; where personal data lives; tests and how releases reach production; and who on the team knows what. They will also want time with your technical lead, usually more than once.

Start with ownership: make sure the company, not a founder or a contractor, holds every account, repository and domain, and that everyone who wrote code signed an IP assignment. Then remove former staff from systems, move shared passwords into a password manager, test a restore from backup and write a short system overview. Check frameworks and dependencies against their support dates, and open-source licenses such as GPL and AGPL against how the product is distributed. All of it is cheaper before a buyer finds it. A red-flag memo tells you where to begin.

We cannot promise any effect on price, in either direction. What tends to happen is this: a problem a buyer discovers late in exclusivity arrives without context and with little time, and it is often priced at the worst case. The same problem found early is either fixed or presented with a plan and a cost. Buyers expect imperfect technology; what unsettles them is surprise. Our fee is fixed and has nothing to do with the price, so the report says what it finds.

You decide, with your advisor. The buyer report is written to be shared under the usual confidentiality terms, and it works best when every serious buyer sees the same facts, so the competition between them stays about price. Some sellers share it only with buyers who reach a later round. The seller report, with the full findings and the fix plan, stays with you and your advisors. The engagement letter sets who may receive each report.

Not by itself. Many good products were built by outside teams. Buyers will check three things: that the agency assigned all rights in the work to the company, that the company rather than the agency holds the accounts and repositories, and that someone can keep the product running if the agency relationship ends. When one of these is missing, it can usually be put right before a sale with signed paperwork, an account transfer and a planned handover.

Before the first document changes hands. We sign our own mutual NDA or the one the deal parties already use, whichever is faster. Until then, please do not send confidential material: the contact form asks only for a short description of the deal. On the buy side, the seller often requires reviewers to sign the deal NDA or a joinder to it, and we do. Everyone on our team is bound by confidentiality obligations before they see anything.

Read-only access to the code repositories and cloud consoles, the main system documents and a few interviews. Access goes through named accounts, one per person on our team, for the period of the review; we do not use shared logins. We never need write access to production and do not ask for it. Everything we receive is listed, and the list is part of the report. At the end, access is closed and we confirm it in writing. The full access protocol is on our approach page.

Only as much as we need to see where it lives, who can reach it and how it is protected. We do not copy personal data. Where we need to see data, we look at it in place with the company's team or at masked samples. A common finding is production data copied to a test server without masking. If the company handles regulated data, such as health records or payment card data, we ask for the relevant policies and evidence of controls rather than the data itself.

The engagement letter sets it before we start: the report, our working notes and the list of materials received, for a stated period. We keep no personal data. Access to the company's systems is closed when the review ends, and we confirm in writing what we keep and for how long. If the deal does not happen, the same applies, and the NDA stays in force for the period it states. You can ask us at any time what we hold.

With as little disruption as we can. We agree one technical contact, send a written request list after the scoping call and plan interviews in advance, usually three to five conversations. Questions are batched rather than sent one at a time. We are specific and courteous, we do not criticize the people who built the product, and we do not discuss the deal with staff who are not part of it. Small teams are busy running the company, and we plan around their week.

That is common. Many sellers keep a sale confidential from most staff until it is signed. We work only with the people the seller has brought inside, use the project name the deal uses, and keep requests to what those people can answer. If the person who knows a system best is outside the circle, we tell the seller what we would ask them and what is lost without the conversation, and the seller decides. The report states any such limit.

The client who commissions it, and whoever the engagement letter names. On a buy-side review, that is the buyer and its advisors; the seller sees it only if the buyer chooses to share it. On vendor due diligence, the seller report stays with the seller and its advisors, and the buyer report goes to buyers under confidentiality terms. Lenders and insurers receive a report when the client agrees and the engagement letter covers it. We never pass a report to anyone on our own initiative.

Every engagement has one fixed fee, agreed in writing before we start. It depends on the number and size of the products, the systems and environments behind them, the depth of the review and the timeline, not on the size or outcome of the deal. We scope it on a short call under NDA and send a proposal with what is in scope, what is out, the report date and the fee. We do not publish fees, because two companies with the same revenue can differ widely in what there is to read.

No. We are paid the same whether the deal closes, changes price or falls apart. A success fee would give us a reason to soften findings, for a buyer who wants to close or for a seller who wants a clean report. Without one, the report has no reason to lean either way. The same holds for exit readiness: a fixed monthly fee, with nothing tied to the sale or its price.

Usually something nobody mentioned at scoping: a second product, a business unit with its own systems, a mobile app maintained by a separate contractor, or a large internal system the product depends on. Sometimes access arrives much later than planned and the report date has to move. In each case we stop, explain what changed and agree the new scope, date and fee in writing before doing the extra work. A fee never grows quietly, and you can always decide to keep the original scope.

A red-flag memo usually takes 5 to 10 business days after access. A full technical due diligence usually takes 2 to 4 weeks, inside exclusivity. Vendor due diligence usually takes 3 to 5 weeks, followed by Q&A support during the sale process. Exit readiness runs monthly for at least 4 months, ideally starting 6 to 18 months before a sale. The report date is fixed in the proposal, and the clock starts when access is in place.

Deals stop for many reasons. The engagement letter states up front what happens if you end the review early: what we deliver from the work done so far and how the fee is settled. We agree it before we start so nobody has to negotiate it under pressure in the middle of a deal. If the deal comes back later, the earlier work can count toward a new review, depending on how much the company has changed in the meantime.

Yes. If the memo shows the deal needs a closer look, the work already done counts toward a technical due diligence on the same company, and the proposal for the full review reflects that. The same applies to a seller who starts with a memo and moves on to vendor due diligence or exit readiness. Nothing is read twice, and the findings keep their numbers, so the second report can be compared line by line with the first.

The people named in the proposal. We introduce them by name before you sign, and they are the people who do the work, not a junior team behind them. Every review is led by a senior engineer and checked by someone with deal-side experience, so the findings are technically right and framed in terms a deal team can use. If a review needs a specialist outside our team, we say so in the proposal and name that person too. More on the team.

Web and mobile products, SaaS platforms, e-commerce and internal business systems, built on mainstream stacks and hosted with the major cloud providers or on the company's own servers. Products that depend on something specialized, such as embedded firmware, regulated medical software or custom machine learning models, need a specialist for that part. When that is the case we say so in the proposal and either bring the specialist in under the same terms or leave out the part we cannot read properly. We never review a layer we are not equipped to judge.

Our focus is United States deals in the lower middle market. Many US companies have developers, contractors or servers abroad, and we review those as part of the company. When part of the review depends on another country's law or language, for example local data protection rules or contracts written in another language, we say so in the proposal and either bring in a local specialist or leave that part to local counsel. Companies based outside the US we discuss case by case.

Not as part of the review, and the fix is never priced or sold inside it. The report gives each finding a cost and time to fix, with assumptions, so you can hand it to any team. If you want help, our engineering partner PERETZ can do the work under a separate contract. That is never a condition, and you are free to use your own team or anyone else. On exit readiness, we check the fixes the same way whoever makes them.

PERETZ is a software and design company under common ownership with The Structure, and we say so plainly. Three rules keep the review independent. The fix is never priced or sold inside the review. Using PERETZ is never a condition, and the report is written so any team can act on it. And if PERETZ has ever worked on a company we are asked to review, we disclose it before we start and decline if it could affect our view. See what independence means in practice.

Yes. Advisors bring us in to check a sell-side client before going to market, or to answer technical questions during a process so they do not stall the deal. We report to the client who engages us, keep the advisor informed as the client wishes, and never contact buyers or sellers without the advisor. We do not arrange, negotiate or execute transactions: we are not a broker-dealer, and we give no legal, tax, accounting or investment advice and no valuation. See how we work with advisors.