# The Structure

> Independent technical due diligence and exit readiness for software M&A. Code, infrastructure, data and ownership, read before the deal. Fixed fees, no success fee. Seattle, Washington.

The Structure reviews software companies for buyers, sellers, search funds, independent sponsors and their advisors. Six layers: ownership and IP, infrastructure and cost, data and privacy, code and architecture, security and access, team and knowledge. Every finding carries a severity (Critical, High, Medium, Low), the evidence, the business impact and a rough cost and time to fix. Engineering partner: PERETZ (https://peretz.agency); fixes only under a separate contract, never as part of a review. Contact: hello@thestructure.io, https://thestructure.io/contact/ (reply within one business day).

## Services

- [Technical due diligence services](https://thestructure.io/services/): Strategic options review, red-flag memo, technical due diligence, vendor due diligence and exit readiness for software companies. Fixed fees.
- [Strategic options review for owners](https://thestructure.io/services/strategic-options-review/): Two private calls with an M&A advisor and a written report: where your company stands with buyers, which path fits, and whether you need an advisor at all.
- [Red-flag memo for software deals](https://thestructure.io/services/red-flag-memo/): A focused technical review of the issues that can change the price or stop a software deal. Ranked findings and rough costs to fix, usually in 5 to 10 days.
- [Technical due diligence for buyers](https://thestructure.io/services/technical-due-diligence/): A full independent review of a software company before you buy: ownership, infrastructure, data, code, security and team, with a fix plan and costs.
- [Vendor technical due diligence for sellers](https://thestructure.io/services/vendor-due-diligence/): A technical review commissioned by the seller and shared with buyers. Find issues first, fix or explain them, and run a faster sale process.
- [Exit readiness for software founders](https://thestructure.io/services/exit-readiness/): A monthly program for founders 6 to 18 months before a sale: technical baseline, fix plan by value impact, monthly tracking and a mock buyer review.

## Company

- [Home](https://thestructure.io/): See the structure before you sign.
- [Our approach to technical due diligence](https://thestructure.io/approach/): The six layers we read in every software company, what we check in each, how we rate findings and cost to fix, and how we handle access.
- [Who we serve](https://thestructure.io/who-we-serve/): Founders and boards, search funds and independent sponsors, private equity and strategic buyers, and M&A advisors who need an independent technical read.
- [About: independent technical due diligence](https://thestructure.io/about/): An independent technical due diligence firm in Seattle, Washington. Deal-side people and senior engineers, fixed fees, no success fee.
- [FAQ: technical due diligence](https://thestructure.io/faq/): Answers on technical due diligence for software deals: what it covers, buying and selling, access and confidentiality, fixed fees and timing.
- [Technology deadlines for owners](https://thestructure.io/notes/): End of support, major releases and new rules for the technology a company runs on: dated, checked against official sources and read for owners and buyers.
- [Contact](https://thestructure.io/contact/): Preparing a sale or looking at a target? Tell us about the deal. We reply within one business day and sign an NDA before any documents change hands.

## Insights

- [All insights](https://thestructure.io/insights/): Notes from the reviewer's desk.
- [Mail sent with a password: the Microsoft 365 change that reaches a deal](https://thestructure.io/insights/microsoft-365-smtp-auth-in-a-deal/): At the end of 2026 Microsoft 365 stops password-based mail sending by default. Why it reaches a deal, what a reviewer checks, what a seller can fix now.
- [The standard we ask of others, applied to ourselves](https://thestructure.io/insights/own-systems-own-standard/): We ask every company we review who really controls its technology. Here is how we answered that question for ourselves, and why we keep the blueprint private.
- [Symfony 6.4, Drupal 10 and PHP 8.2 in a deal that closes in 2027](https://thestructure.io/insights/symfony-drupal-php-support-deadlines-in-a-deal/): Three support deadlines end within five weeks in late 2026. What they mean for a deal closing in 2027, what a buyer checks and what a seller can still do.
- [Before you hire an M&A advisor, get a second opinion](https://thestructure.io/insights/second-opinion-before-hiring-an-ma-advisor/): Who buys companies like yours, which paths exist besides a full sale, what moves value, and how to check any advisor's incentives before you sign.
- [Technical debt in 2026: demand, review prices and repair costs](https://thestructure.io/insights/technical-debt-review-and-repair-costs/): How large technical debt is, how much buyers look for it, what a review and a repair cost on the open market, and why finding and fixing should stay apart.
- [How a buyer reviews the AI coding agents inside a company](https://thestructure.io/insights/ai-coding-agents-due-diligence/): Coding agents now hold keys to code and servers. How a buyer reviews AI agent use in a software company, layer by layer, and how we run our own.
- [What a migration changes when nothing is supposed to change](https://thestructure.io/insights/migration-claims-due-diligence/): What we found moving our own site to a new framework, and how a reviewer checks a seller's claim that a re-platforming changed nothing.
- [What a technical due diligence reads, and what it does to the deal](https://thestructure.io/insights/technical-due-diligence-for-buyers/): What a reviewer reads in a software company, the evidence behind each finding, and how a rating becomes price, escrow, an indemnity or a 100-day plan.
- [Who will buy your software company, and what their technical review looks for](https://thestructure.io/insights/technical-review-by-buyer-type/): Strategic acquirers, PE platforms, add-ons and searchers read the same code for different plans. What each review weighs, and how a seller prepares.
- [Due diligence on a product written largely with AI](https://thestructure.io/insights/ai-written-code-due-diligence/): When much of a product's code came from AI tools, tidy code proves little. What a reviewer checks, how findings are rated, and keep, fix or rebuild.
- [Carve-outs: the systems a business shares with its parent](https://thestructure.io/insights/carve-out-shared-systems-due-diligence/): When the business you buy runs on its parent's cloud, code, licenses and people, the review must find every shared system and price the separation.
- [An aging platform inside an acquisition target](https://thestructure.io/insights/aging-platform-in-an-acquisition/): The target runs on a platform past end of support. How a reviewer reads patches, extensions and hosting, prices the ways out and frames the deal points.
- [What a well-built product looks like to a reviewer](https://thestructure.io/insights/signs-of-a-well-built-product/): What a reviewer accepts as proof that software was built to last, why strengths belong in a diligence report, and how sellers can make them visible.
- [A technical baseline before the banker](https://thestructure.io/insights/technical-baseline-before-selling/): Technology is the part of a software company you can still change before a sale. How to baseline it, pick fixes and keep the banker's story true.
- [The technology claims in your sale document, read by the reviewer who will test them](https://thestructure.io/insights/technology-claims-in-a-sale-document/): Proprietary, scalable, secure, no technical debt: how a buyer's reviewer tests each claim in a CIM, and how to word it so the evidence holds.
- [Technical checks before you buy a small software company](https://thestructure.io/insights/technical-checks-before-buying-a-software-company/): For search funds and independent buyers: what to check before the LOI, what to ask for in exclusivity, and how lenders read a technical finding.
- [How technical debt is measured and put into a deal](https://thestructure.io/insights/technical-debt-in-due-diligence/): Why "the code has tech debt" tells a buyer nothing, and how a reviewer turns debt into findings with evidence, cost ranges and a place in the deal.
- [The technology behind the SaaS numbers](https://thestructure.io/insights/technology-behind-saas-gross-margin/): A buyer pays for recurring revenue and gross margin. A technical review checks whether the product can keep producing those numbers after closing.
- [Key-person risk in the technology: what a reviewer looks for](https://thestructure.io/insights/key-person-risk-technical-due-diligence/): One founder who can deploy, one contractor who knows billing. How a reviewer finds key-person risk in the system, rates it, and what a seller can fix first.
- [AI tools in technical due diligence: what they can and cannot do](https://thestructure.io/insights/ai-tools-in-technical-due-diligence/): Can a model do the technical review now? Where AI tools help a reviewer, where they fail, and what to ask any provider about deal data and evidence.
- [Ownership gaps that stop a software deal](https://thestructure.io/insights/ownership-gaps-software-acquisition/): Code in a founder's account, a cloud root held by a contractor, a missing IP assignment. Which gaps stop a deal, and how control is proven and moved.
- [AI diligence: is it a product or a wrapper?](https://thestructure.io/insights/ai-product-or-wrapper-diligence/): Every target says it uses AI. Here is how a buyer checks what is owned, what is rented, and what the model bill does to the margin after closing.
- [The technical section of the data room, from the reviewer's desk](https://thestructure.io/insights/data-room-technical-section/): What a technical reviewer opens first in your data room, what each document must prove, and the gaps that turn one file into fifty questions.
- [The diligence report is the first draft of your 100-day plan](https://thestructure.io/insights/from-due-diligence-to-100-day-plan/): What to close before closing, what goes into the first 30 days, the 100-day plan and the first year, and how to prove a fix is done.

## Authors

- [Yevhen Borovoi](https://thestructure.io/authors/yevhen-borovoi/): Founder of PERETZ, DeZZign, The Structure and NEX. Partner at SCHOEFFEL.
- [Valeriia Chumachenko](https://thestructure.io/authors/valeriya-chumachenko/): Head of Advisory & Advisor to Founder, The Structure

## Optional

- [Privacy policy](https://thestructure.io/privacy/): How The Structure LLC handles personal information on thestructure.io: what we collect, why, how long we keep it and how to reach us.
- [Terms of use](https://thestructure.io/terms/): Terms of use of thestructure.io, the website of The Structure LLC, Seattle, Washington.
- [Glossary](https://thestructure.io/glossary/): Plain definitions of the terms of software M&A and technical due diligence.
- [Sitemap (HTML)](https://thestructure.io/sitemap/): Every page of the site, grouped.
- [Sitemap](https://thestructure.io/sitemap.xml)