--- title: "Technology Architecture: The Gap Between What the Code Encodes and What the Company Knows" description: "Technology architecture diligence tests whether the company knows its own system, not whether the system is good: a current and approved architectural definition, a component and dependency inventory, a decision record, and ownership that does not rest on one person. Where this layer is missing, valuation treats the technology not as an asset but as an assumed rebuild obligation." url: https://www.beirek.com/en/blog/technology-architecture-due-diligence canonical: https://www.beirek.com/en/blog/technology-architecture-due-diligence published: 2026-07-11 modified: 2026-07-11 category: "Technology & Engineering" category_url: https://www.beirek.com/en/blog/category/technology-engineering language: en-US reading_time_minutes: 8 publisher: BEIREK LLC publisher_url: https://www.beirek.com license: "© BEIREK LLC — citation with attribution and link permitted" keywords: ["technology architecture due diligence","architecture decision record","dependency inventory and license regime","key-person dependency valuation discount","technical due diligence documentation"] topics: ["Technical due diligence and investment readiness","Software architecture governance and ownership","Third-party dependency and license exposure","Key-person dependency and transaction structuring"] alternate_language_url: https://www.beirek.com/tr/blog/technology-architecture-due-diligence --- # Technology Architecture: The Gap Between What the Code Encodes and What the Company Knows > **In short:** Technology architecture diligence tests whether the company knows its own system, not whether the system is good: a current and approved architectural definition, a component and dependency inventory, a decision record, and ownership that does not rest on one person. Where this layer is missing, valuation treats the technology not as an asset but as an assumed rebuild obligation. *In most companies the technology architecture is not a document but an understanding held in scattered form across a few people's memories. The diligence table looks for that understanding in written, approved and person-independent form; failing to find it, what it finds gets priced not as technology but as technology risk.* --- There is a scene that recurs in the opening session of a technology review. Asked for the architecture, the counterparty typically produces a page lifted from a sales deck — boxes, arrows, a cloud icon, three tiers. Later in the same session, when a senior member of the engineering team is asked how the system actually operates, several material divergences surface between the described system and the diagrammed one: a service shown as singular has split into two in production, a queueing layer absent from the page sits squarely on the critical path, and a component still drawn in the middle tier was decommissioned two years earlier. Nobody has misrepresented anything. The diagram was accurate on the day it was drawn; the system then continued to move, and the diagram did not. For diligence purposes, the finding here is not that the architecture is weak but that the architecture is not an object the company knows at an institutional level. A second scene emerges a few hours into the same session. Asked why a particular design decision was taken — why this database, why this synchronous call, why this third-party service — the answer usually follows a familiar shape: it was decided that way at the time, the person who decided is no longer with the company, and nobody is willing to change it because what would break is unknown. Recorded by the reviewing party, that answer registers not as a technical detail but as a statement of obligation: the company can operate certain parts of its own system but cannot modify them. The mechanism underneath both observations is not negligence; it is an entirely rational shortcut. In the early period, architecture forms in a room where a handful of people share the same context and settle a question in five minutes, and in such a room the marginal benefit of documenting the decision is low while its cost comes directly out of development hours. Shared verbal context, when the team is small, is both faster and more accurate than a written architecture, precisely because it updates continuously. The difficulty lies not in the shortcut itself but in the quiet disappearance of the condition that made it valid: as the team grows, as founding engineers move into management, and as every newly joined engineer is left to reconstruct context by reading code alone, the shared mental model disperses — yet because the written layer that would have replaced it was never established, the resulting gap goes unnoticed. Knowledge is not lost; it loses its accessibility. The most expensive form of that loss appears in the dependency layer. A modern application carries third-party components at several times the volume of its own written code, and those components fall into categories that behave very differently: libraries whose license regime makes commercial use conditional, projects no longer under active maintenance, and external services priced against consumption volume. All three sit side by side in the same build artifact while representing legal exposure, operational exposure and margin exposure respectively. In a dependency set without an inventory that distinction is never drawn, and when it is drawn for the first time during diligence, the findings that surface are typically of the sort that extend the closing calendar rather than the sort that can be dispatched in a footnote. The practice dimension sits apart from documentation and is frequently the more decisive of the two. The presence of a current architecture document does not establish that engineers make daily decisions in accordance with it, and the most practical indicator of the distance between the two is how violations of an architectural constraint are handled. Where a breach is caught in code review and opened for discussion, the architecture functions as a live constraint; where it is discovered months after release, by way of an incident, the document is a statement of intent. The reviewing party establishes this distinction not by reading the document but by examining recent change history for how many different ways the same decision has been implemented — the same function solved through three distinct patterns being the clearest available evidence that the architecture was never established at the level of practice. Measurement is the dimension most often left empty in technology architecture, because what needs measuring runs against intuition. So long as the system runs, there is assumed to be nothing to measure; yet measuring an architecture means measuring not whether the system works but how it will behave under growth. How infrastructure cost per unit transaction moves with volume, how long it takes a newly hired engineer to make a first meaningful contribution, how long a change takes to travel from idea to production, and what share of production incidents recur in the same component — these indicators describe the behavior of an architecture against scale far more reliably than the architecture document itself. Where they are not tracked, the technology side of the growth case in the business plan remains unverifiable, and an unverifiable case is treated at investment committee not as optimistic but as risky. What is sought in the ownership dimension is not a title but a decision right. Most companies have a person responsible for technology architecture, yet that person frequently holds no authority to reject an architectural decision, to halt use of a component, or to allocate sprint capacity toward servicing technical debt; in practice that authority rests with whoever controls the product calendar. Under such a configuration, architecture retreats in predictable fashion at every conflict between commercial pressure and technical necessity, and the accumulation of those retreats becomes, some years later, the principal determinant of scaling capacity. The question asked at the diligence table is therefore not who owns the architecture but which architectural decision was rejected in the last twelve months, by whom, and on what stated grounds; an ownership structure unable to produce an example of a rejected decision is, functionally, indistinguishable from no ownership at all. Continuity is where these layers converge, and it is the dimension that connects most directly to valuation. Where only one individual can speak to the critical portions of a system, that individual's retention ceases to be a human resources matter and becomes a term of the transaction structure; key-person covenants, earn-out triggers and pre-closing knowledge transfer conditions all originate at this point. The valuation effect here arises not from technology risk but from founder or key-engineer dependency, and on the buy side that dependency is generally priced through two line items: the rebuild cost expected across the first eighteen months following acquisition, and the opportunity cost of the product development capacity deferred during that same window. Both items pull the cash flow projection down directly, and neither is easily argued away with a demonstration of system quality. Correcting this picture does not require a comprehensive architectural rewrite; what it requires are four distinct mechanisms that convert the architecture into an object the company knows. The first is an architectural definition describing the system as it actually stands and updated alongside change — not boxes and arrows, but component boundaries, data ownership and the contracts between components. The second is a decision record capturing, for every material architectural decision, its rationale, the alternatives considered and the trade-off accepted; this record is the only mechanism preventing the rationale from departing with the person who made the decision. The third is a dependency inventory classified by license regime and maintenance status. The fourth is an enforcement layer in which architectural constraints are actually applied at code review and through automated checks rather than asserted in a document. BEIREK's intervention in this area is not to substitute for the engineering team but to construct the translation layer between an engineering decision and an investment decision. In practice that begins with mapping the system as it actually stands at component and dependency level, then fixing in a single record, for each critical component, its ownership, its decision authority and its transferability status; the purpose of that record is to ensure the questions the reviewing party will ask have already been asked inside the company. The second layer converts the recording of architectural decisions from an archival exercise into a rhythm tied to the moment of decision: the rationale is written when the proposal is made, not when it is approved, since a rationale written after approval records not the decision but its subsequent defense. The third layer is the regular reporting of a deliberately limited set of indicators describing how the architecture behaves against scale — the unit cost curve, change lead time, the concentration of recurring incidents, and the time required for a new engineer to reach a productive threshold. These indicators are not performance measures for the engineering team; they constitute the only evidentiary chain against which an investment committee can verify the growth case, and for that reason they are operated on the same calendar as financial reporting rather than on an engineering cadence. The fourth layer is a rotation discipline ensuring that at least two people hold working-level competence in each critical component, which is what converts the continuity dimension from a statement of good intent into a condition capable of being audited. The value of a company's technology surfaces not in how well that technology works but in how well the company knows the way it works, since what a buyer acquires is not a functioning system but a transferable capability. The distance between the architecture document placed on the table and the system described by the engineer is the most direct available measure of how far those two things have diverged — and that distance is not something that can be closed once diligence has begun. ## Key Points - The question posed at the diligence table is not how well the system performs but whether the way it performs is known, in documented form, at the level of the company rather than the individual engineer. - Where architectural decisions go unrecorded, each decision hardens over time into a constraint without a rationale, and the cost of reversing it accumulates quietly across years. - Companies lacking a dependency inventory, a license classification and a map of third-party services typically face a widened representations and warranties package and an escrow ratio calibrated upward. - Architecture that resides in a single person's head is priced not as technology risk but as key-person dependency, and that discount is usually structured as earn-out mechanics and retention covenants. - Without a measurement layer, the cost of scaling cannot be estimated, which renders the growth case in the business plan unverifiable rather than merely optimistic. ## Questions ### Which documents are requested for technology architecture during technical due diligence? Four document sets are typically requested: a current architectural definition showing component boundaries, data ownership and inter-component interfaces; a decision record holding material design decisions together with their rationale and the alternatives considered; a dependency inventory classified by license regime and maintenance status; and a register showing ownership and transferability status for each critical component. A diagram drawn for a sales deck does not substitute for this set. ### Why does the absence of architecture documentation reduce a company's valuation? The reduction stems not from poor technology but from an inability to demonstrate transferability. Facing an undocumented architecture, a buyer writes into its own projection both the rebuild cost expected in the period following acquisition and the product development capacity deferred during that period. Those two items depress cash flow directly; separately, the representations and warranties package widens and the escrow ratio is calibrated upward. ### How should an architecture decision record be maintained, and why is it written before approval? For each material decision, the context, the alternatives evaluated, the path selected and the trade-off accepted are recorded briefly. Capturing the record at the moment of proposal is decisive, since text written after approval documents not the decision itself but a defense constructed for it afterward. A record made at proposal is the only mechanism ensuring the rationale remains with the company when the person who made the decision departs. ### Which indicators should be measured for technology architecture? The indicators that matter show not whether the system works but how it will behave under scale: how infrastructure cost per unit transaction moves with volume, how long a change takes from idea to production, how densely production incidents recur within the same component, and how long a newly hired engineer takes to make a first meaningful contribution. Together these four form the evidentiary chain capable of verifying the technology side of a growth case. --- Source: https://www.beirek.com/en/blog/technology-architecture-due-diligence Publisher: BEIREK LLC — https://www.beirek.com