Build Proprietary. Buy Commodity.

Every growing software team makes the same capital mistake.

An engineer looks at a SaaS bill and decides to build in-house. The math seems simple. Why pay thousands of dollars a month for auth, billing, or queues when a team can write a working tool in a sprint? It handles logins, stores tokens, and passes tests. The team ships it and calls the build pure savings.

They read their balance sheet backwards.

Software is a liability paid for with your scarcest asset: engineering time. Writing the first version is always the cheapest part of owning code. The friction of typing used to act as an economic brake. When web frameworks made initial builds fast, they did not make custom software free. They made it easy to write risky bets against your team’s focus.

Costs are never fixed

Teams always underestimate total cost of ownership. They price an internal project by the two weeks it takes to build, while ignoring the five-year operational tail.

Accounting calls code authoring capital spend: cash turned into assets. In production, code works in reverse. New code adds immediate technical debt. Maintenance is the rent you pay every month to keep the system up.

In software economics, writing was never the main bill. Barry Boehm showed in Software Engineering Economics (1981) that post-release upkeep eats 50% to 75% of lifetime software costs. Robert Glass added in 2002 that roughly 60% of maintenance goes to reading and changing existing code. Bug fixes take only 17%. Decades earlier, Edsger Dijkstra noted in EWD1036 (1988) that we should count lines as lines spent rather than lines produced.

When a team builds custom plumbing, like an auth tool, a billing system, or a queue, they cut only the first 15% of the bill. The other 85% of total lifecycle cost stays untouched:

1. Protocol drift and API churn. Payment gateways, identity standards, and tax rules update every year. A custom adapter demands constant rework so it does not break.

2. The verification bottleneck. Writing code is fast, but human reading is slow. Every line of bespoke code demands code reviews, integration testing, and on-call mental effort.

3. The security tail. In-house code lacks the shared testing of open source or cloud platforms. It collects security bugs in quiet isolation.

When you buy commodity software, you rent an external team for a fraction of one developer’s salary. That team fixes bugs, tracks new rules, and runs security checks around the clock. Building in-house throws that external help away and forces your best engineers to patch plumbing.

Wisdom from the grey beards

Data from industry studies and production history shows this gap. The findings fall into three clear layers:

The controlled and structural evidence. Strategy models set the frame. Geoffrey Moore drew the line in Dealing with Darwin (2005) between Core (work that wins deals) and Context (everything else). His rule is direct: pull engineering resources out of context to fund core work. Simon Wardley mapped this in Wardley Maps (2016). He showed that building a custom tool for what is already a product or utility creates heavy drag. The limit of these models is qualitative: they give strategy advice rather than automated code gates.

The observational telemetry. Industry studies reveal the heavy downstream tax of maintaining non-core software. Stripe’s Developer Coefficient (2018) found that developers spend 42% of their work week on technical debt and maintenance, creating an estimated $300 billion annual drag on global output. That baseline matches Gartner’s IT spending data (2020) showing that typical enterprises commit 70% to 75% of their tech budgets to run-rate operations. The limit here is observational: these numbers come from surveys and budgets rather than live IDE logs.

The personal-experience baseline. Senior operators reach this view from real outages. Dr. Werner Vogels defined undifferentiated heavy lifting (2006) at AWS: every line of plumbing you write is code you must run, patch, and debug without gaining a customer edge. Dan McKinley framed the innovation token model (2015) at Etsy: an organization gets three innovation tokens to spend, and burning them on databases or queues steals focus from your product. Will Larson noted in Build versus buy (2020) that internal tools rot because teams rarely fund permanent staff to maintain them. The limit here is firm size: rules from large shops may overstate the drag for small teams.

How to decide build vs buy

To keep custom code from turning into deep debt, every internal build must pass four checks in design review:

1. The customer choice test. Will a customer buy your product over a rival because you built this internal subsystem yourself? If not, building it in-house is a capital error.

2. The vendor failure test. Has your team tested one commercial tool and two established open-source projects, and proven that all three fail under production load?

3. The lifetime budget test. Does the project proposal set aside three times the initial build hours for yearly maintenance, patches, and on-call rotations?

4. The token budget test. Does this project spend an innovation token on commodity plumbing that could fund your core product?

If a project fails any check, pick a standard open-source tool or buy a commercial service.

Where judgment compounds

The true advantage in engineering has always been managing consequences rather than typing code.

When tech teams grow, leaders often judge power by how many tools a team built from scratch. That metric is upside down. Code is cheap to write. Protecting your team’s focus is expensive.

Every hour spent fixing custom session code or patching an internal queue is an hour stolen from your core product.

Senior engineering judgment shows in what you refuse to maintain.