Consider two proposals that arrive in the same planning cycle.

The first is a vendor quote. A platform that handles a capability your product needs — identity, billing, search, observability, whatever it happens to be — costs $120,000 per year. The number sits on the page with unusual clarity. Finance can put it in a spreadsheet. Procurement can negotiate it. Someone will ask whether the discount improves with a three-year commitment. The figure is annoying in the way that all recurring costs are annoying, but it is legible.

The second proposal comes from engineering. Three developers believe they can build an internal version in roughly four months. The proposal contains no invoice. It contains a Gantt chart, a short architecture sketch, and a sentence about how the team already understands the domain better than any vendor could. Nobody circulates a number, because the work will be absorbed by salaries the company is already paying.

Compared side by side, the second option frequently looks cheaper. It rarely is, and the reason has less to do with engineering estimation than with accounting visibility. A vendor quote is a price. An internal build is a commitment whose cost is disclosed slowly, in fragments, across years and across budget lines that nobody consolidates.

The build proposal describes the creation of version one. It usually does not describe who maintains the system in year three, who patches the dependency with a critical vulnerability on a Friday evening, who upgrades the framework when the current major version reaches end of life, who answers the support ticket when a customer's data does not appear, who writes the documentation that lets a new hire understand the system, who owns the migration when the platform architecture changes underneath it, and who understands any of it after the engineer who wrote it leaves the company. It also does not describe the customer-facing work that will not be built during those four months, which is often the largest cost of all and the one that never appears in any budget.

This is the core asymmetry in software ownership economics. A vendor charges you for access to something you do not own. Building gives you ownership, and ownership arrives bundled with every obligation ownership creates. The interesting question is not which of those is cheaper in the abstract. It is when the ownership is strategically valuable enough to be worth the obligations, and when it is a liability the company has volunteered to carry indefinitely because the initial estimate looked manageable.

That question does not have a universal answer, and any article that gives you one is selling something. Buying is not automatically the disciplined choice; plenty of companies have outsourced their way into products that cannot do anything a competitor cannot also do. Building is not automatically the ambitious choice; plenty of engineering organizations have spent years maintaining infrastructure that no customer has ever noticed. What follows is an attempt to structure the decision honestly, working through the cases where the answer is genuinely hard.

---

The comparison that starts the argument in the wrong place

Most build-versus-buy conversations begin with a comparison that is not wrong so much as incomplete in a way that reliably biases the outcome.

On one side: vendor cost, expressed as an annual subscription. On the other: internal cost, expressed as headcount multiplied by duration. Three engineers for four months. Five engineers for a quarter. The units differ, but that is not the problem. The problem is that the first number describes a recurring obligation and the second describes a one-time event, and comparing them treats software as something that gets finished.

Software does not get finished. It gets released, and then it enters the phase where most of its cost lives. This is one of the older findings in software engineering research and one of the most consistently ignored in business planning. The foundational survey work by Lientz, Swanson, and Tompkins, published in Communications of the ACM in 1978, found that maintenance and enhancement consumed the majority of application software effort in the organizations they studied, and that error correction was only a minority of that work. Most maintenance was adaptive and perfective — keeping software working as its environment changed, and extending it as requirements evolved. Subsequent estimates vary widely in their exact percentages, and anyone quoting a precise universal figure should be treated with suspicion, but the direction has held across five decades of study: the initial build is a minority of lifetime cost.

A more useful frame separates the money into three categories, and then applies all three to both options. Build and buy each have acquisition, ownership, and exit costs. They differ in how those costs are distributed, who absorbs them, and how visible they are at the moment of decision.

The table is not a scorecard. It is a reminder that the two options are structurally symmetric, and that the visible cost of each is drawn from a different row. When you buy, acquisition and ownership costs are largely visible and exit costs are hidden. When you build, acquisition cost is partially visible and ownership and exit costs are almost entirely hidden. Decisions made on visible cost alone therefore have a systematic tilt, and the tilt runs toward building.

Two propositions follow, and they are worth holding in tension because most bad decisions come from accepting one and forgetting the other. The cheapest system to acquire is not necessarily the cheapest to own. And the cheapest system to own is not necessarily the best strategic decision, because there are capabilities worth paying to own even when renting would be cheaper.

---

Total cost of ownership, without pretending to precision

Total cost of ownership models have a credibility problem in engineering organizations, and the problem is deserved. Most TCO analyses produce a number with two decimal places derived from a dozen assumptions, each of which could be off by half. The number then becomes the argument, and the assumptions stop being examined.

The alternative is not to abandon the exercise. It is to build the model as a range and treat it as a structured way of asking questions rather than as a forecast. A directional TCO model that surfaces a category the team had not considered is more valuable than a precise one that omits it.

For a capability you would build, the recurring categories look roughly like this: initial implementation, integration with the rest of the system, infrastructure to run it, annual maintenance and dependency upkeep, security and compliance work, internal support, upgrade and modernization work as the surrounding platform changes, the expected cost of incidents, general operational overhead, the eventual cost of replacing or retiring it, and opportunity cost.

For a capability you would buy: subscription or license fees with an assumption about annual increases, implementation, integration, ongoing administration, training, work that exists only because the vendor requires it, the risk-weighted cost of price changes, and eventual switching cost.

The category that gets mishandled most often is the cost of engineering time, and it gets mishandled in two directions at once.

The first error is using salary as the unit of cost. A fully loaded engineering cost includes compensation, employer taxes and benefits, recruiting and onboarding amortized over tenure, management and coordination overhead, equipment, software tooling and licenses, and a share of infrastructure and internal platform costs. The multiple on base salary varies by geography and company structure, and any specific figure quoted as a universal benchmark should be verified against your own finance data rather than borrowed from a blog. What matters is that the number is meaningfully above salary and that the model uses it consistently.

The second error is larger and more consequential: treating engineering capacity as though it were free once the headcount is fixed. If five engineers spend six months building internal authentication infrastructure, the relevant question is not only what those engineer-months cost. It is what those five engineers did not build. Opportunity cost is the dominant term in most build decisions at companies under a few hundred engineers, and it is the term least likely to appear in the analysis, because it requires naming the roadmap items that will slip and no one enjoys writing that memo.

Opportunity cost also behaves differently from other costs. Infrastructure spend is recoverable — you can turn servers off. Six months of product development that did not happen during a competitive window is not recoverable at all.

Here is a comparison across the dimensions that actually differ, with no winner declared, because the winner depends entirely on which rows matter to your business.

Notice that "predictability" cuts both ways, which is one of the more counterintuitive rows. Buying is more predictable over one to three years and less predictable over five to ten, because vendor pricing is subject to change and yours is not. Building is unpredictable early and can become quite stable once a system reaches maturity and stops changing. The horizon you choose for the analysis determines which option looks safer, which is why the horizon should be argued about explicitly rather than assumed.

---

The differentiation test, and why it is harder than it sounds

The most useful single question in this entire decision is not financial. It is this: does this capability contribute meaningfully to why customers choose us over an alternative?

If the honest answer is yes, building deserves serious consideration, and the cost analysis becomes a question of affordability rather than justification. If the honest answer is no, then owning the capability creates permanent operational responsibility in exchange for no competitive position, and the burden of proof should sit heavily on whoever proposes to build it.

The examples are easy at the extremes. A payments company has a defensible reason to build sophisticated payment orchestration, routing, and retry logic, because the quality of that orchestration is visible in authorization rates and therefore in customer economics. A project management SaaS gains nothing from operating its own email delivery infrastructure; customers evaluate the product on collaboration workflows, not on how the reminder email reached them. A cybersecurity company probably needs proprietary detection capability, since the detection is the product. A CRM startup does not need to build video conferencing. A product whose entire value proposition is finding the right result in a large, messy corpus may well need proprietary retrieval and ranking. A payroll platform almost certainly needs to own its jurisdiction-specific calculation logic, because that logic encodes the domain expertise customers are paying for.

The general principle is straightforward: build differentiation, be cautious about building utilities. It is also insufficient on its own, and the failures of this principle are more instructive than its successes.

Commodity infrastructure becomes strategic under a specific set of conditions, and each of them is observable in advance if you are looking. Vendor limitations start blocking roadmap items you actually want to ship. Usage scale moves far enough that unit economics invert. Data requirements turn out to be unusual enough that generic tools model them badly. Latency becomes a product characteristic rather than an implementation detail. Regulation changes what you are permitted to do with third parties. Integration depth grows until the capability is no longer separable from the product. Or control itself becomes the advantage, because customers are choosing you specifically for guarantees a vendor cannot make on your behalf.

None of those conditions means "you should have built it from the start." They mean the classification changed, and classification is not permanent.

A three-tier model is more useful than a binary one, because it captures the middle case that causes most of the arguments.

The strategic enabler row is where most of the real difficulty lives, and where the largest architectural mistakes get made in both directions. Teams that treat enablers as commodities end up with products that are constrained in ways they cannot fix. Teams that treat enablers as core differentiators end up with beautiful internal platforms and a thin product.

One more caution about this test: the answer changes depending on who you ask, and the person who most wants to build something is rarely the person best positioned to assess whether customers care about it. Run the question past sales and customer success before accepting engineering's classification. If the capability has never appeared in a competitive evaluation, a lost-deal report, or a customer's requirements document, it is probably not a differentiator no matter how technically interesting it is.

---

From buying software to owning a capability

There is a reframing that changes these conversations more than any spreadsheet, and it is a single substitution: stop asking whether to build or buy a piece of software, and start asking whether you want to own a capability for the next five years.

Software is an artifact. A capability is an ongoing organizational commitment that includes people who understand it, processes for changing it, monitoring that tells you when it breaks, a security posture, a support path for the humans who use it, a test suite that lets you modify it safely, documentation that survives turnover, an architecture that can absorb change, a budget line, and a succession plan for when the people who built it move on. Software is what you produce in the first four months. The capability is what you are still paying for in year five.

The distinction between writing software and operating software is the one most consistently underestimated in build proposals, and it is not a matter of engineering skill. Excellent engineers build working systems quickly. The gap appears afterward, in the unglamorous work that turns a working system into an operational one: alerting that distinguishes real failures from noise, runbooks that let someone other than the author respond at 3 a.m., backup and restore procedures that have actually been tested, capacity planning, dependency upgrade cadence, access control that survives an audit, and the accumulated small hardening that happens only after a system has been broken in production a few times and fixed.

A working prototype and an operational capability differ by roughly an order of magnitude in effort, and the multiple is larger for anything that touches money, identity, or customer data.

This is why the phrase "we already built a version of it" is such a weak argument for continuing. The prototype demonstrates that the problem is tractable. It says almost nothing about whether the organization is prepared to operate the result indefinitely.

Code is frequently the least expensive phase of long-term software ownership. That claim resists precise quantification and should be treated as a directional observation rather than a measured constant, but the mechanism is easy to see: writing code is a bounded activity with a clear endpoint, while operating software is an unbounded activity that ends only when the system is decommissioned. As a system ages, the ratio moves further in that direction, because the code changes less and the environment around it changes more.

The practical implication is that build decisions should be evaluated by the people who will operate the result, not only by the people who will write it. If the on-call rotation has no representation in the decision, the decision is being made with half the information.

---

Authentication: the trap that keeps working

Authentication is the canonical example, and it stays canonical because the trap works on experienced teams. It is worth examining in detail — not as an implementation guide, but as a case study in how a capability's true surface area reveals itself only after commitment.

The version that gets estimated is small and genuinely is small: a login form, password hashing, session management, a password reset flow, maybe email verification. A competent engineer can build that in a sprint. The estimate is not wrong about the work described.

The estimate is wrong about the product. What organizations discover they need, usually in the order their customers demand it, is a substantially larger system: single sign-on, SAML for enterprise identity providers, OAuth and OpenID Connect for everything else, multi-factor authentication across several factor types, configurable password and session policies, account recovery flows that resist social engineering, device and session management with the ability to revoke a session immediately, role and permission management, audit trails detailed enough to satisfy an enterprise security questionnaire, automated user provisioning and de-provisioning through SCIM so that customers' IT departments can manage lifecycle centrally, brute-force and credential-stuffing protection, anomaly detection, tenancy isolation, and the documentary evidence required for SOC 2 or ISO 27001 audits.

Each of those arrives as a reasonable customer request. Individually, none of them looks like a project. Collectively, they are a product — one with its own roadmap, its own security review cadence, its own compliance obligations, and its own permanent maintenance load. The team that estimated three weeks for login is now staffing an identity platform, and doing so with a team that has other responsibilities.

The failure mode is not that the team cannot build these things. It is that nobody made a decision to build them. The decision was made once, for a small scope, and then extended incrementally by customer pressure until the organization was operating identity infrastructure it never chose to own.

The lesson is not "never build authentication." It is: understand which product you are volunteering to maintain, and make that decision explicitly at the point where the scope actually gets set.

There are real cases where building identity infrastructure is defensible. When identity is itself the product or a central differentiator, ownership is not optional. When regulatory requirements are unusual enough that no vendor's architecture fits — certain government, defense, healthcare, or national data-residency contexts — the constraint may force the decision. When authentication is entangled with a highly specialized workflow, such as delegated access models or complex multi-party authorization that vendors treat as an edge case, the extension points may not exist. When scale changes the economics so severely that per-user identity pricing becomes a material share of gross margin, the calculation shifts. And when control over the authentication path is itself something customers are paying for, ownership is part of the value proposition.

What separates a defensible build from an accidental one is that the defensible version starts from the full scope, is staffed as a product, and has a named owner in year three.

---

Billing: where "just add a payment provider" stops being simple

Billing follows the same pattern with a different shape, and it is instructive because it demonstrates that the build/buy question decomposes rather than resolving.

Payment processing is a solved problem that almost nobody should build. The regulatory surface, the card network requirements, the fraud tooling, and the settlement infrastructure make in-house payment processing a poor use of engineering capacity for anyone whose business is not payments.

Billing is not payment processing. Billing is the set of rules that determines what a customer owes, and those rules encode your commercial strategy. The layers accumulate quickly: recurring subscriptions with plan changes, proration when a customer upgrades mid-cycle, usage-based components metered accurately enough to survive a customer's audit, tax calculation across jurisdictions with different rules for digital services, refunds and partial refunds, credits and account balances, invoicing that satisfies enterprise accounts payable departments, multi-currency pricing and the question of who bears exchange risk, negotiated enterprise contracts with custom terms and minimum commitments, pricing experiments that require running multiple models simultaneously, entitlement logic that determines what a customer can actually access based on what they bought, revenue reconciliation between the billing system and the general ledger, dunning and recovery flows for failed payments, and reporting that finance trusts enough to close the books with.

Some of that is infrastructure. Some of it is your business model expressed in code.

The distinction that matters is between using a billing provider and outsourcing your pricing model. A company can route payments through a provider, use that provider's subscription primitives, and still build proprietary entitlement and pricing logic on top — because pricing strategy changes frequently, and a company whose pricing changes are gated on a vendor's data model has surrendered something more important than money.

This is the first clear appearance of a pattern that recurs throughout the rest of this analysis, and it is the pattern most likely to be the right answer for a mature product: buy the infrastructure, build the differentiation. The infrastructure is the part that is hard, regulated, undifferentiated, and expensive to operate. The differentiation is the thin layer where your decisions live. Companies that get this wrong in one direction build payment processing. Companies that get it wrong in the other direction discover that they cannot launch a usage-based tier because the vendor's model does not support it.

---

Five categories, examined briefly

Not every capability deserves the same depth of analysis, and treating them uniformly is itself a mistake. What follows is deliberately uneven, because the decisions are uneven.

Search. Hosted search is sufficient for a large majority of products, and the threshold for building is higher than engineers instinctively believe. Full-text search over a moderate corpus with conventional relevance expectations is a solved problem, and the operational burden of running a search cluster — index management, reindexing without downtime, capacity for spiky query loads, relevance regression testing — is significant enough that outsourcing it is usually correct.

The threshold moves when relevance itself becomes the product. If your customers evaluate you on whether the right result appears first, and if "right" depends on domain knowledge that generic ranking cannot capture, then ranking is a core differentiator even though the underlying index is a commodity. The correct architecture in that case is frequently a purchased or open-source engine with proprietary ranking, feature extraction, and evaluation on top. Scale, latency requirements, and per-query pricing shift the line further, and hybrid retrieval requirements have made this decision more common rather than less.

Analytics. The word covers four distinct capabilities that get conflated in planning discussions, and separating them resolves most of the disagreement. Internal product analytics — understanding how users behave — is well served by existing tools and rarely worth building. Business intelligence for internal reporting is similar. Customer-facing analytics, where your users see dashboards inside your product, is a different problem: it is part of your product surface, it must match your data model, it carries your performance and design expectations, and embedding a third-party tool often produces something that looks and behaves like a third-party tool. The data platform underneath — how events are modeled, stored, and made queryable — is infrastructure that increasingly determines what the other three can do.

Generic tools work well until the questions become specific to your domain. The point at which a custom data model creates differentiation is usually the point at which customers start asking questions your event schema cannot answer.

Content management. Engineering teams underestimate CMS work with remarkable consistency, and the reason is a category error: they estimate the storage and rendering problem, which is simple, rather than the editorial workflow problem, which is not. The hidden product surface includes role-based permissions granular enough for a real content team, review and approval workflows, revision history with meaningful diffs and rollback, scheduled publishing, preview environments that accurately reflect production, localization with translation state tracking across many locales, asset management with variants and rights metadata, structured content modeling that survives redesigns, and search across unpublished content.

Every one of those is a request that arrives after launch from a marketing or content team that assumed it was standard, because in commercial products it is. A homegrown CMS is one of the most reliable ways for an engineering organization to acquire a permanent internal customer with an unbounded backlog.

Notifications. "Send the user a message" is a deceptively small statement. The operational reality includes deliverability management — domain authentication, reputation monitoring, bounce and complaint handling, avoiding the spam folder — plus user preference management across channels and message types, template systems that non-engineers can safely edit, localization, retry logic with sensible backoff, unsubscribe handling that satisfies regulation in every jurisdiction you operate in, rate limiting and batching to avoid overwhelming users, graceful degradation when a provider has an outage, and delivery tracking that lets support answer "did the customer receive it?"

Sending is easy. Delivering reliably at scale is a specialty, and it is a specialty in which vendor infrastructure carries reputational assets you cannot replicate quickly.

Monitoring and observability. Most teams should buy substantially more of this than they build, particularly early. Observability tooling is a mature market, the operational cost of running your own metrics, logging, and tracing infrastructure is high, and the failure mode is uniquely bad: the system that tells you whether everything else is working goes down at the same time as everything else.

The counter-case is real at scale and is driven mostly by cost. Usage-based observability pricing scales with data volume, and data volume scales faster than revenue for many architectures. Large organizations therefore build internal layers — sampling and filtering pipelines, cost allocation, routing between hot and cold storage tiers, and domain-specific dashboards that encode how their teams actually work. That is a composition decision rather than a replacement: the underlying storage and query engines are usually still purchased or open source. The trigger for revisiting is typically an observability bill that has become a visible percentage of infrastructure spend, which is a specific, measurable event rather than a general suspicion.

---

Internal tools: the interesting exception

Internal tooling deserves separate treatment because the usual analysis inverts. The differentiation test says these tools are commodities — no customer chooses you because your operations team has a good refund interface. And yet building them is frequently correct.

The reason is that internal tools encode workflows that are genuinely unique to your business. A commercial tool is designed for the average case across many customers; your operations process is a specific case that evolved around your product and your organization. The cost of bending a purchased tool to fit an unusual workflow can exceed the cost of building something that fits exactly, particularly when the tool has few users, needs no marketing-quality interface, and requires no support organization. Modern internal tooling frameworks have lowered the build cost further, and AI-assisted development has lowered it again.

Custom internal software is rational when the workflow is genuinely idiosyncratic, when the operation is high-repetition enough that small efficiency gains compound, when the domain requirements are specific, when the user base is small and trainable, and when the interface can be plain without cost.

The hidden expenses are consistent, though. Permissions become a real problem the moment more than one team uses the tool, because internal tools have a habit of accumulating access to systems well beyond their original scope. Data integrity matters more than it appears to, since internal tools frequently write to production data with fewer safeguards than customer-facing paths. Maintenance is real but unfunded, because internal tools rarely have a product owner and their backlog competes with customer work and always loses. Employee turnover hits internal tools harder than product code, because they are less documented and less reviewed. Processes evolve, and tools that encode a process become obstacles when the process changes. Reporting requirements appear later, usually from finance. And auditability becomes mandatory the first time an auditor asks who approved a particular adjustment.

The most useful principle here is that the correct quality level depends on blast radius, not on whether the user is internal or external.

An ugly internal tool is fine. A slow one is usually fine. An internal tool that can issue refunds, modify entitlements, alter financial records, change permissions, or export customer data is a system whose failure modes include fraud, data loss, and regulatory exposure, and it deserves the engineering rigor that implies: authorization checks, immutable audit logging, approval workflows for high-impact operations, tested rollback paths, and automated tests around the destructive operations.

This is where testing strategy becomes an economic question rather than a hygiene question. The right amount of QA for an internal dashboard that displays a chart is close to none. The right amount for the tool that adjusts customer balances is the same as for the customer-facing product, because the consequences are the same. Organizations that apply a single standard to everything internal get this wrong in one direction or the other, and the expensive error is the one where an unreviewed internal script quietly corrupts production data for six weeks before anyone notices. Assessing that blast radius honestly — and sizing the quality investment to it — is exactly the kind of evaluation that benefits from an outside perspective, which is one of the areas where QAtronic's technical assessment and test automation work tends to be applied.

---

AI infrastructure poses the same question in unfamiliar clothing

The AI stack has produced a fresh crop of build-versus-buy decisions, and the novelty of the technology has obscured how ordinary the underlying question is. Model APIs, vector databases, agent orchestration frameworks, prompt and context management, evaluation and observability tooling, model routing layers, retrieval pipelines, fine-tuning infrastructure, and GPU capacity are all layers where a company must decide what to own.

The mistake that recurs is a syllogism: we are an AI company, therefore we should own the AI stack. It does not follow, and the market data available in 2026 suggests most successful builders have concluded the same thing. ICONIQ's 2026 State of AI research, based on surveys of a few hundred executives at software companies building AI products, found that roughly half of respondents identified application-layer innovation — user experience, workflows, integrations, and how data is applied — as their primary source of differentiation, while only a small minority pointed to proprietary model development. Builders are also using multiple model providers rather than committing to one, which is itself a portability decision.

The productive question is where differentiation actually lives, and the candidates are specific: proprietary data that no competitor can obtain, the workflow into which the AI is embedded, evaluation infrastructure that tells you whether quality is improving, domain logic that constrains and corrects model output, the customer experience around uncertainty and error, orchestration across models and tools, fine-tuning where it produces durable advantage, and — rarely — infrastructure itself.

Evaluation deserves particular attention as a build candidate. Generic benchmarks say little about whether your system works for your users on your data. An evaluation harness that encodes your quality definition, your failure taxonomy, and your regression suite is a genuine asset, it compounds over time, and it is difficult for a competitor to copy because it embeds accumulated judgment about what "correct" means in your domain. It is also the layer that makes everything below it replaceable: with a strong evaluation framework and a clean abstraction, changing models becomes an experiment rather than a project.

The opposite failure is real too. Complete dependence on external providers creates exposures that show up on the income statement and in the roadmap. Inference cost sits in cost of goods sold, and AI product margins have been running well below the 70–80 percent range that traditional SaaS businesses were built on — ICONIQ's surveyed builders reported average gross margins in the low fifties for 2026, improving but structurally below software norms. That gap is a direct consequence of variable costs that scale with usage. Latency is bounded by the provider. Vendor concentration creates a single point of failure for a core product capability. Provider policies constrain what data can be processed and where. And product capabilities are limited to what the provider exposes.

The reasonable posture is neither. Buy the models and most of the infrastructure. Build the evaluation, the orchestration logic, the domain constraints, and the data assets. Keep the abstraction boundaries clean enough that the purchased layers remain swappable, and treat model routing and cost discipline as engineering work with direct margin consequences rather than as an optimization to do later.

---

The price curve, and the mistake hidden inside it

The strongest quantitative argument for building is that vendor pricing and internal cost scale differently. A vendor that is inexpensive at small scale can become expensive at large scale, because most vendor pricing is a function of something that grows with your business: seats, API calls, transactions processed, events ingested, gigabytes stored, or documents indexed. Internal infrastructure cost grows too, but usually more slowly, and often with step functions rather than linearly.

The most thoroughly documented public example is 37signals, the company behind Basecamp and HEY, which moved its applications off public cloud onto owned hardware in colocated data centers. The company disclosed cloud spending above $3.2 million in 2022, spent several hundred thousand dollars on servers, and reported in late 2024 that its first full year after migration produced savings of roughly $2 million annually, exceeding the original projection of $7 million over five years. Their public accounting of the migration is unusually transparent and worth reading in full.

It is also a specific case with specific preconditions, and treating it as a general endorsement of repatriation is exactly the error this section is about. 37signals had stable, predictable workloads that did not benefit much from elasticity, an experienced operations team, a colocation partner handling physical infrastructure, and a business with mature products rather than rapidly changing requirements. Their public statements are consistent that they added no new staff, which is the pivotal detail: they already had the operational capability. A company without it would have to acquire it, and that acquisition cost is not in the $2 million.

Which brings us to the mistake that undermines most break-even analyses: comparing future vendor cost against current internal development estimates.

Internal costs scale too. Support volume grows with users. Infrastructure grows with load, and grows faster than linearly if the architecture was designed for a smaller scale. Engineering ownership expands as the system accumulates edge cases; a system that one engineer maintained at 10,000 users may need a small team at a million. Security and compliance obligations increase with customer sophistication and data volume. Reliability expectations tighten as customers grow larger, and moving from 99.5 percent to 99.95 percent availability is not a linear increase in effort. On-call coverage that was tolerable as a side duty becomes a rotation that requires staffing.

A break-even model that is honest about this has a shape roughly like:

Annual vendor cost = fixed platform fees + (usage × unit price), adjusted for expected annual price changes and volume discount tiers.

Annual internal cost = infrastructure + engineering ownership (a fraction of one or more FTEs, fully loaded) + support + security and compliance work + maintenance and upgrades + expected incident cost, with the initial build amortized across the expected life of the system.

Both sides are uncertain, so both should be expressed as ranges rather than points. Three scenarios, built on explicitly stated assumptions, communicate far more than a single break-even year.

The numbers in that table are illustrative placeholders, not benchmarks. The structure is the point. If the break-even only appears in the optimistic column, the decision is being made on hope. If it appears in all three, the economic case is genuinely strong and the remaining questions are about capability and strategy rather than cost.

One further caution: break-even calculations assume the vendor's price and your requirements both stay recognizable. Over five years, neither reliably does.

---

Vendor lock-in is real. So is the lock-in you build yourself

Engineering teams worry about vendor lock-in, and they are right to. The concern is usually well-informed and the examples are recent.

Licensing terms change. HashiCorp moved Terraform and its other products from the Mozilla Public License to the Business Source License in August 2023, restricting use in competing offerings; the community forked the last MPL-licensed release into OpenTofu, which was donated to the Linux Foundation. IBM subsequently acquired HashiCorp in a deal announced in April 2024 and completed on 27 February 2025, valued at approximately $6.4 billion in enterprise value. Redis moved off the BSD license in March 2024 to a dual source-available model, prompting the Valkey fork under Linux Foundation governance; Elastic had made a comparable move in 2021, prompting OpenSearch. Both Elastic and Redis later added AGPL options, which is instructive: even reversals do not reverse migrations that have already happened.

Acquisitions change commercial terms more abruptly than license changes do. Broadcom completed its acquisition of VMware in November 2023 and moved rapidly to eliminate perpetual licensing in favor of subscriptions, consolidate a large product catalog into a small number of bundles, and revise minimum purchase requirements. Customers reported substantial renewal increases across 2024 and 2025, and the episode became the reference case for what happens when a widely deployed infrastructure vendor changes hands.

And services simply end. Google announced in August 2022 that Cloud IoT Core would be discontinued a year later, giving customers with deployed device fleets twelve months to migrate connections, authentication, and data pipelines to something else.

Those are the visible forms of vendor lock-in: proprietary APIs with no equivalent elsewhere, data formats that resist export, pricing power that grows with your dependence, contract terms that constrain your options, and ecosystem dependencies that multiply the surface area of any migration.

What gets discussed far less is that internally built software creates lock-in of its own, and that this variety is frequently harder to escape because it has no contract, no renewal date, and no external party forcing the conversation.

The row about political difficulty is the one that surprises people. Vendor migrations are painful but conceptually clean: there is a deadline, a budget, and an external party to blame. Replacing an internal system requires an organization to conclude that its own prior work should be discarded, and organizations are structurally bad at that. Sunk cost operates more powerfully on internal assets than on external ones, because internal assets carry authorship.

The objective is not zero lock-in, which is unattainable. Every architecture creates switching costs, and a system with no switching costs at all is usually a system that has not been integrated deeply enough to be useful. The objective is lock-in that is acceptable in magnitude and understood in advance.

For purchased capabilities, the concrete questions are: can we export our data in a usable form, and has anyone actually tested that export? Are there documented APIs for everything we depend on, or are we relying on undocumented behavior? How much proprietary integration code have we written, and where does it live? Does a credible substitute exist today, and roughly what would substitution cost?

For internal capabilities: is it documented well enough that a new engineer can make a change safely? Can someone other than the original author operate it? Could it be replaced without touching the rest of the product? How many other systems call it, and how deeply do they depend on its specific behavior rather than its interface?

---

Security and compliance: responsibility does not transfer with the workload

Buying a security-sensitive service moves work. It does not move accountability.

This is the substance of the shared responsibility model that every major cloud and SaaS provider publishes, and the widespread misreading of it is a genuine risk. The provider secures their infrastructure and platform. You remain responsible for how you configure it, what data you put in it, who you grant access to, how you handle credentials, and whether the overall system meets your regulatory obligations. When customer data is exposed through a misconfigured storage bucket or an over-permissive access policy, the provider's certifications are not a defense.

Regulators have been making this explicit rather than leaving it to interpretation. The EU's Digital Operational Resilience Act, which has applied since 17 January 2025, requires in-scope financial entities to maintain a register of ICT third-party arrangements, manage concentration risk, contract for specific resilience terms, and retain board-level accountability for ICT risk — including risk that sits with providers. It also establishes direct oversight of ICT providers designated as critical to the sector. The regulatory position is that outsourcing the function does not outsource the obligation. (Worth noting for anyone searching: this DORA is unrelated to the DevOps Research and Assessment program whose annual reports share the acronym.)

Neither option is inherently more secure, and the honest comparison is a matter of matching failure modes to organizational reality.

Buying a security-critical capability brings specialized expertise you probably cannot hire at your size, continuous updates against threats you would not otherwise track, certifications that shorten enterprise sales cycles, and dedicated security teams whose full-time job is this narrow problem. It also brings third-party exposure, the possibility of a vendor breach that becomes your incident, misconfiguration risk that is entirely yours, data processing arrangements that require legal analysis, and dependence on the vendor's disclosure practices and patch timelines.

Building brings control over policy and data location, the ability to implement requirements no vendor supports, and in some architectures a genuinely smaller external attack surface. It also brings full ownership of vulnerability discovery and remediation, responsibility for patching every dependency on the vendor's timeline rather than your own, the need for security expertise on staff or on retainer, ongoing security testing, and the complete compliance evidence burden — which is substantial and recurring, because auditors want evidence of continuous control operation rather than a one-time assertion.

The organizations that handle this well tend to be honest about a specific question: do we have, and will we continue to have, the specialist capability to secure this ourselves at the standard our customers and regulators expect? A team that cannot maintain a dependency upgrade cadence is not going to run a secure identity system, regardless of how the initial implementation looks.

A vendor can own infrastructure. Your company still owns the business risk.

---

The maintenance multiplier

What happens after version one is where the economics are decided, and it is the part of the analysis most likely to be waved through.

Software that receives no new features still generates work, because it does not exist in isolation. It interacts with browsers that update, operating systems that change security defaults, third-party APIs that deprecate endpoints, cloud services that retire instance types or runtime versions, language runtimes that reach end of life, package ecosystems where a transitive dependency ships a critical vulnerability, infrastructure that gets migrated, product architecture that evolves around it, customers who ask for things, employees who need to understand it, and compliance frameworks that add requirements.

Each of those generates maintenance regardless of whether anyone is improving the software. The classic taxonomy from the Lientz and Swanson research distinguishes corrective maintenance (fixing defects) from adaptive maintenance (keeping software working as its environment changes), perfective maintenance (improvements and new requirements), and preventive maintenance (work done to avoid future problems). Their finding — replicated in various forms since — was that corrective work is the minority. Most maintenance is adaptive and perfective. Most of it, in other words, is not caused by bugs.

This produces the idea worth carrying out of this section: a software system can stop receiving features without stopping its cost.

The practical consequence is that "we'll build it and then it will be done" is not a plan, and neither is "we'll maintain it opportunistically." Deferred maintenance does not disappear; it accumulates and converts into migration work at a worse exchange rate. A dependency upgrade skipped for three years is not three years of saved effort. It is a project, sometimes a blocking one, and it arrives on a schedule chosen by a CVE rather than by you.

There is a second-order effect worth naming. Systems that are not actively maintained become systems that people are afraid to change. Fear of change is expensive in ways that never appear as maintenance cost: features get routed around the fragile system, workarounds accumulate, and the architecture bends to avoid touching it. By the time the organization decides to replace it, the replacement is harder than it would have been three years earlier, and the estimate has grown for reasons that have nothing to do with the original scope.

A reasonable planning heuristic is to fund ongoing ownership explicitly as a percentage of the original build effort per year, choose the percentage based on how much environmental churn the system is exposed to, and treat that funding as non-negotiable rather than as capacity to be reallocated whenever the roadmap gets tight. The specific percentage matters less than the fact that it exists and has an owner.

---

Key-person dependency, on both sides

A custom internal platform is frequently one senior engineer's institutional memory converted into code. The system works because that person understands both the domain and every decision embedded in the implementation, including the ones that were never written down and the ones that were made for reasons that no longer apply.

That arrangement is efficient right up until it is not. The failure triggers are ordinary: resignation, extended leave, a reorganization that moves the person to another team, a promotion into management, or an acquisition that changes everyone's priorities. None of these is unlikely over a five-year horizon. In aggregate, over five years, at least one of them is close to certain.

The mitigations are unglamorous and known: documentation written for someone who was not there, code ownership shared by more than one person, deliberate cross-training rather than the assumption that anyone could pick it up, architectural simplicity chosen over cleverness where the tradeoff exists, automated tests that let a stranger change the code with some confidence, and operational runbooks tested by someone other than their author. What makes them hard is not difficulty but priority: every one of them competes with feature work and loses, because the cost of skipping them is deferred and the cost of doing them is immediate.

It is worth resisting the temptation to overstate this, though, because purchased software creates dependencies too. Vendor-specific expertise is a real skill that takes time to acquire and walks out the door the same way. Administrators who understand a complex configuration are as scarce as engineers who understand a custom service. Implementation consultants leave behind configurations that nobody internally fully understands. Certain enterprise platforms have created entire consulting economies precisely because in-house expertise is hard to sustain.

The difference is in the recovery path. When vendor expertise is lost, replacements exist: a market of trained practitioners, vendor support, documentation, and a user community. When the person who built an undocumented internal system is lost, the recovery path is reverse engineering, and the cost is bounded only by the system's complexity. That asymmetry is the argument, and it is an argument for documentation and shared ownership rather than an argument against building.

---

Time has an economic value, and so does keeping your options open

Build-versus-buy comparisons routinely treat schedule as an engineering detail. It is a business variable, and often the dominant one.

If buying allows a product to launch two quarters earlier, the effects compound: revenue arrives sooner and funds the next stage, customer feedback arrives sooner and redirects the roadmap before more is invested in the wrong direction, market position is established before a competitor's, fundraising happens against traction rather than against a plan, and enterprise deals with long procurement cycles start earlier. Two quarters of learning is worth more than two quarters of revenue for most early-stage companies, because it changes what gets built next.

Faster is not automatically better, and the caveat matters. A purchased capability that constrains the product later imposes a cost that may exceed the time saved, particularly if the constraint appears after the product has been built around it. Speed acquired by accepting an architectural ceiling is borrowed, not earned.

The concept that resolves most of this tension is option value. Buying frequently preserves future choice rather than foreclosing it, which is the opposite of the usual intuition. Committing engineering months to build infrastructure is an irreversible allocation of the scarcest resource a young company has. Buying the same capability defers the commitment, and defers it until you know considerably more about what you actually need.

This produces a sequence that is close to a default strategy for early-stage products:

Buy first. Learn what the requirements really are. Identify where differentiation actually emerges. Then build selectively, and only there.

The reason this works is that requirements discovered through operating a real product with real customers are dramatically better than requirements imagined during design. A team that has run a purchased search product for eighteen months knows exactly which relevance failures cost them deals. A team that built search from scratch at month three built it against assumptions.

The strategy has one serious failure mode, and it should be evaluated before adopting it. It only works if the eventual migration is feasible. If the purchased capability holds data that cannot be exported in usable form, if the integration surface becomes deeply entangled with the product, if migration would require simultaneous cutover across many systems, or if switching would visibly disrupt customers, then "we can replace it later" is a claim that has not been tested. The time to evaluate exit feasibility is at the point of purchase, when you have leverage and no sunk investment, rather than at the point when you want to leave.

Option value is real, but only for options you can actually exercise.

---

Build, buy, adopt, or compose

The binary framing is convenient and increasingly wrong. Modern architecture offers at least four postures, and the most sophisticated decisions usually combine several.

Open source needs a specific caution, because "free" is a licensing statement rather than an economic one. Running open-source infrastructure yourself means you own hosting, capacity planning, upgrades, security patching, backup and recovery, monitoring, and the expertise to operate it under load. That is the ownership cost column of the build option, with the development cost removed. For some teams that trade is excellent. For teams without operational depth, self-hosting a database or a search cluster is a build decision wearing a different label.

What open source genuinely offers is the elimination of license cost, a reduction in a certain kind of vendor lock-in, source-level visibility when something breaks, and freedom to customize. What it does not eliminate is governance risk, as the relicensing events of the last few years demonstrated. Projects controlled by a single commercial entity can change terms; projects under neutral foundation governance are more stable but not immune. The practical mitigation is to evaluate governance structure alongside technical fit, and to prefer projects where a fork would be viable if it became necessary.

The composition pattern is where most good answers land, and the examples generalize:

Buy authentication infrastructure, build authorization and the business rules that determine what a user may do in your domain. Identity is a commodity; your permission model encodes your product.

Buy payment processing, build pricing and entitlement logic. The rails are regulated infrastructure; your pricing is strategy.

Buy cloud infrastructure, build the deployment platform and paved paths that fit how your teams work. DORA's 2025 research on AI-assisted software development found that the large majority of surveyed organizations had adopted internal platforms, and that platform quality correlated strongly with whether other investments paid off — a useful reminder that the thin layer of internal tooling on top of purchased infrastructure is often where the leverage is.

Buy model APIs, build domain-specific workflows, evaluation, and constraints.

Buy or adopt a search engine, build ranking, feature extraction, and relevance evaluation.

The common shape is that the purchased layer handles the physics — moving bytes, storing data, executing computation, satisfying regulation — while the built layer handles the judgment. Judgment is what customers pay for, and judgment is what a vendor cannot supply, because it is specific to your business.

Drawing that boundary well is the actual skill. Draw it too low and you rebuild infrastructure. Draw it too high and your product logic ends up expressed in a vendor's configuration language, where it is neither portable nor testable nor fully yours.

---

A decision model that structures the argument rather than replacing it

Frameworks that reduce this decision to a checklist produce confident answers to questions they did not understand. What follows is intended to organize a disagreement between people who know the business, not to substitute for one.

Score each dimension from 1 to 5. A high score indicates that the dimension favors building; a low score favors buying. The value is in the discussion each row produces, and particularly in the rows where people disagree.

Two rules make this usable rather than decorative.

First, do not average the scores and act on the result. Some dimensions are dispositive on their own. A capability with genuinely no strategic differentiation and a mature vendor market should be bought even if six other rows score high. A capability where regulation forbids third-party processing must be built regardless of cost. The framework surfaces those conditions; it does not weigh them.

Second, record the assumptions, not just the scores. Six months later, the useful artifact is not "we scored 34." It is "we scored operational burden low because we assumed the platform team would absorb it, and that assumption is no longer true." Scores decay. Assumptions are testable.

The single most common failure in applying a framework like this is scoring "internal expertise" against the ability to build rather than the ability to operate. Most teams that can build a thing can build it. Fewer can run it for five years while also doing their actual jobs.

---

Reasons to build that deserve a second look

Each of the following can be a legitimate reason. Each is also, frequently, a rationalization arriving after a decision that was made on other grounds.

"We can build it better." Sometimes true, and specifically true when the vendor is optimizing for a median customer whose needs differ from yours. The question that separates the two cases is: better along which dimension, and does that dimension matter to a customer? "Better" that means cleaner code or a more elegant model is an engineering preference. "Better" that means a measurable improvement in something a customer evaluates is a business case.

"We don't want another subscription." This is a real concern about cost creep and vendor sprawl, and it is also the most reliably misleading argument in the set, because it compares a visible recurring cost against an invisible one. The internal alternative also has a recurring cost; it is simply paid in engineering capacity rather than in invoices. If the argument is being made by someone who owns a software budget but not an engineering budget, the incentive structure is worth noting out loud.

"Our developers can finish it quickly." Usually accurate about version one and systematically inaccurate about the operational system. This argument should be tested by asking what "finished" includes: does it include audit logging, monitoring, documentation, tests, an on-call runbook, and the enterprise features customers will request in the first year?

"We want full control." Control is genuinely valuable, and the question is what specific control is needed and what it costs. Control over data location may be non-negotiable. Control over the release schedule of a login form is probably not worth a permanent maintenance obligation. Naming the specific control converts a preference into a requirement that can be evaluated.

"The vendor is expensive." Possibly the strongest argument on the list, and it becomes rigorous the moment it is expressed as a comparison of fully loaded five-year costs including ownership. Before that, it is a reaction to a visible number.

"We already built half of it." This is sunk cost, and it is worth being explicit about the logic. Money and effort already spent are not recoverable by either choice, so they should not influence the decision at all. The only relevant question is which path is cheaper from today forward. Half-built systems are also systematically misleading about remaining effort, because the first half is usually the tractable half; the remaining work is integration, edge cases, operational hardening, and the features that were deferred precisely because they were hard.

"We might need customization later." Optionality has value, and this argument is stronger when the customization is specific and foreseeable and weaker when it is hypothetical. "We will need to support a per-transaction pricing model in Q3" is a requirement. "We might want to change something eventually" is an argument that would justify building everything.

"Our engineers want to build it." Worth taking seriously for reasons that have nothing to do with the technical merits. Engineering morale, retention, and the ability to attract strong people are real business considerations, and a team that never builds anything interesting will eventually be a team of people who are interviewing. But enthusiasm is not evidence of strategic value. Engineers are drawn to hard, well-defined technical problems, and the problems that are most appealing to build are frequently the ones that are most thoroughly solved by vendors, precisely because clean problems attract both engineers and product companies.

The symmetric failure is worth naming in the same breath, because this section will otherwise read as an argument against engineering judgment. Executives systematically underestimate technical complexity, because the visible feature surface of most software is small relative to what supports it. A login screen looks like a login screen. The reason non-technical leaders often favor building is the same reason engineers often favor building: both are estimating the part they can see.

The productive conversation happens when engineering explains what the invisible portion contains, and leadership explains what the organization will not be building instead.

---

Reasons to buy that deserve the same scrutiny

"It's faster." Usually true for initial capability and frequently false for the full integration, particularly with enterprise platforms where implementation timelines run to quarters. It also says nothing about whether the speed is worth what it costs later.

"Everyone uses it." Market adoption is real evidence about reliability and viability, and it is not evidence about fit. Widespread use also means widespread constraint: if a capability is a differentiator for you and everyone in your market buys the same implementation of it, you have purchased parity.

"Procurement already approved it." An administrative convenience that has become an architectural decision. This is how organizations end up with core product capabilities running on tools selected for an unrelated department.

"We don't want to maintain anything." Purchased software still requires integration maintenance, configuration management, version upgrades on the vendor's schedule, administration, and internal support. The maintenance is smaller and differently shaped. It is not zero, and integration code is some of the least-loved code in most codebases.

"The vendor handles security." Partially true and dangerous as a complete belief, for the reasons covered earlier. The vendor handles their infrastructure. You handle configuration, access, integration, and accountability.

"The integration is only temporary." Temporary integrations have a documented tendency to become permanent, because the conditions that made them expedient rarely improve. If an integration is genuinely temporary, the exit should be designed at the same time as the entry and given an owner and a date. Otherwise it is permanent and should be evaluated as such.

"We can always migrate later." True only if data portability has been verified, the integration surface has been kept narrow, and an alternative actually exists. Untested, this is the most expensive assumption in the set.

The risks on the buy side compound in a particular way. A capability ceiling constrains what your product can ever do in that area. Pricing leverage grows as your dependence grows, and vendors know precisely how deeply integrated you are. API quality determines how much of your engineering time is spent working around someone else's design. Data restrictions can prevent you from building analytics or AI features on your own operational data. Roadmap dependency means your differentiation is scheduled by someone whose priorities are set by their median customer. And acquisition or shutdown risk is not hypothetical, as the last several years have demonstrated repeatedly.

This produces the idea that deserves to sit alongside the maintenance multiplier: the cost of buying includes the things your product will never be able to do.

That cost never appears on an invoice. It appears in the roadmap items that are quietly reclassified as infeasible, in the enterprise deals lost to a requirement you cannot meet, and in the competitor who built the thing you rented.

---

When to reopen the decision

Neither choice is permanent, and treating either as permanent is how organizations end up with infrastructure that made sense for a company they no longer are.

Specific events should trigger a review rather than a general sense that things have changed. Vendor cost rising materially as a share of revenue or gross margin. Usage scale crossing a threshold that changes unit economics. New regulatory requirements affecting data handling, residency, or third-party risk. Vendor limitations blocking a roadmap item that matters commercially. Reliability problems that are visible to your customers as your problem. Internal expertise growing to the point where operating the capability is realistic. The capability becoming strategically important because the market moved. A vendor changing direction, pricing model, or licensing terms. An acquisition changing the commercial relationship. Migration tooling improving enough to change the cost of switching. Credible new alternatives entering the market.

A lightweight practice makes this tractable: maintain a short register of the significant build/buy decisions, each with the assumptions that drove it and the specific conditions that would justify revisiting. Review it annually. Most entries will require no action, and the exercise takes an hour. The value is in catching the two or three where an assumption quietly stopped being true.

The deeper principle is architectural reversibility. When making a decision under uncertainty — which is nearly all of them — the difficulty of changing course later is a first-class design consideration, and often more valuable than getting the answer right today.

Reversibility is bought with specific practices: keeping vendor-specific code behind an interface you own rather than scattered through the codebase, maintaining and periodically testing data export, avoiding vendor-proprietary features when a portable equivalent is close in quality, and documenting the integration surface so that its full extent is known rather than discovered during migration. The same applies internally: a built system designed so that it could be replaced by a vendor product is a system whose ownership remains a choice.

Some decisions are genuinely irreversible, and those deserve disproportionate analysis. Most are not, and treating them as though they were produces analysis paralysis on questions that could be settled by trying something for six months.

---

Before building: the five-year ownership memo

Estimates are optimistic because they describe the work someone is excited to do. A short written artifact, required before authorizing substantial internal infrastructure, is a cheap way to surface what the estimate omitted.

This should be one or two pages, written by the person proposing the build, and reviewed by someone who will be responsible for operating the result. Its purpose is not approval. Its purpose is to make hidden assumptions explicit while they can still be examined.

The eleventh row is the one that changes decisions, and it is the one most often skipped. Requiring a named tradeoff converts an abstract capacity question into a concrete organizational one, and it moves the conversation from engineering to leadership, which is where it belongs.

---

Before buying: the exit memo

The mirror artifact is shorter and should be written before signing anything substantial, when you still have leverage and no sunk investment.

Neither memo needs to be long. Both need to exist before the decision rather than after it, because their entire function is to be inconvenient at a moment when inconvenience is cheap.

The principle underneath both: build decisions require an ownership plan, and buy decisions require an exit plan. A company that produces neither is not making a decision. It is accumulating one.

---

What should a startup build?

Stage changes the answer more than industry does, and the same capability can be an obvious buy at twenty people and a reasonable build at four hundred.

Early stage. Optimize for learning speed, preserve engineering capacity for the product, and keep options open. The scarcest resource is not money; it is the number of things the team can do well at once. Rebuilding mature infrastructure at this stage is nearly always a mistake unless the infrastructure is the differentiation, and the test for that is whether you can articulate the differentiation in a sentence that a customer would recognize.

The nuance is that early-stage companies should still build the thin layers where their product logic lives, even when the infrastructure beneath is purchased. A startup that buys everything including the layer that encodes its own decisions has built a systems integration project rather than a product.

Growth stage. This is where reassessment becomes genuinely valuable, and where most organizations do it too late. Economics change as usage scales. Vendor constraints that were acceptable at ten customers become blocking at five hundred. Reliability expectations rise as customers get larger. Integration depth has grown, often without anyone tracking it. Engineering capability has matured to the point where operating something is realistic.

The characteristic growth-stage error is doing this reassessment in one direction only — noticing the vendor bill and deciding to build, without noticing that the ownership cost also scales.

Large and mature organizations. Internalizing more capabilities becomes rational for reasons that do not apply at smaller scale. Scale economics change the arithmetic. Specialized teams exist and have capacity. An internal platform can serve many product teams, which changes the return on a single investment. Control has more value because there is more to control, and regulatory obligations are typically heavier.

The countervailing observation is that large organizations also accumulate internal platforms that should never have been built, and they are uniquely bad at retiring them. Each one had a plausible justification at the time. Together they represent a substantial share of engineering capacity permanently committed to systems that serve no competitive purpose, defended by teams whose identity is attached to them. Discipline is required at every scale; only the specific failure mode changes.

---

The portfolio view

Every discussion in this article has treated build-versus-buy as a decision about one capability. Organizations make dozens of them, sequentially, each defensible in isolation, and the aggregate is rarely examined.

It should be. Consider a fifty-person engineering organization that owns custom authentication, a custom CMS, custom observability tooling, custom analytics, custom search, custom CI tooling, custom notification infrastructure, and an internal admin framework. Each was built for a reason that made sense at the time. Each has a maintainer, a backlog, an on-call implication, and a security surface.

The relevant question is not whether any individual decision was correct. It is: how much engineering capacity remains for the product customers actually buy? If the honest answer is a minority of the organization, the company has become an infrastructure business that happens to sell an application, and it will lose to a competitor of the same size that made different portfolio choices.

The opposite concentration is equally worth examining. If authentication, billing, data, AI, communications, search, analytics, and the operational platform are all outsourced, and the remaining internal code is primarily orchestration between vendors, the question becomes: where does proprietary technology create defensibility? There may be a good answer — many strong businesses are defended by distribution, brand, network effects, regulatory position, or accumulated data rather than by code. But "nowhere" is a strategic finding, not a neutral state, and it should be arrived at deliberately rather than discovered during a competitive review.

A practical portfolio exercise: list every significant capability in the stack, classify each as core differentiator, strategic enabler, or commodity, and mark whether it is built, bought, adopted, or composed. Then look for the mismatches. Commodities that are built are candidates for retirement. Core differentiators that are bought are strategic exposures. Strategic enablers sitting entirely on one side of the line are usually opportunities for composition.

Most organizations that do this exercise for the first time find at least one internal system that everyone agrees should not exist, and at least one vendor dependency that has quietly become load-bearing for something that matters. Finding either is worth the afternoon. Assessments of this kind — mapping technical complexity, quality risk, operational burden, and migration exposure across an existing stack — are among the engagements QAtronic is most often asked to run, usually at the point where a growth-stage organization is deciding what to keep.

---

Own what deserves ownership

Return to the asymmetry at the start. A vendor's price is visible, singular, and recurring. The cost of internal ownership is distributed across a dozen budget lines, several years, and a set of obligations that nobody consolidates into a number. That difference in visibility is an accounting artifact, and it is doing more work in these decisions than any strategic reasoning.

Correcting for it does not favor buying. It favors deciding on the actual comparison: lifetime cost, strategic value, operational risk, control, and switching cost, evaluated over a horizon long enough for the ownership costs to show up. Some capabilities pass that test easily and should be built with conviction, staffed properly, and defended. Others fail it, and the discipline is in declining them even when the team is capable and enthusiastic, which is precisely when declining is hardest.

There is a final consideration that resists quantification. Every capability an organization owns consumes attention — leadership attention, architectural attention, incident attention, hiring attention, and the diffuse cognitive load of being responsible for one more thing that can break. Attention is more constrained than either money or engineering hours, and it does not appear in any total cost of ownership model. A system can be cheap in every measurable dimension and still be expensive, because someone senior thinks about it during a quarter when they should have been thinking about the product.

The best engineering organizations are not the ones that build the most. They are the ones that are deliberate about what becomes their permanent responsibility, and equally deliberate about what they decline to own — because the list of things a company chooses not to build is, over enough years, as much a description of its strategy as the list of things it does.

---

Build-or-Buy Technical Assessment

Before committing engineering months to building a capability, or years to a vendor, it is worth evaluating the technical ownership cost independently. QAtronic assesses implementation complexity, testing requirements, operational burden, security considerations, integration risk, and long-term maintenance exposure for capabilities under consideration. The output is an evidence-based view of what ownership would actually require — not a recommendation about your strategy, which is yours to make.