The Missing Side of the Ledger

Most people in tech are familiar with the concept of technical debt: the idea that certain shortcuts in development are effectively a loan, and that you pay interest on that loan until you repay it. The interest manifests as time here. Time you have to spend extra today, because things weren’t done right in the past. Left unaddressed, the debt compounds. You cannot build debt-free components on top of debt-tainted ones, so every new feature takes out another loan, and progress gets slower and slower. This ends in one of two ways: either you repay the debt, or your velocity collapses toward zero. Since zero velocity is incompatible with staying in business, accumulated technical debt eventually gets management’s attention, and repayment at that point usually means a rewrite.

Because so many of us have lived through this cycle, the notion that technical debt is bad and should be reduced is well established. But here is the thing: a balance sheet has two sides. Debt reduction is purely defensive. A team that does nothing but pay down debt ends up, at best, at zero.

The other side of the ledger is what we call software capital: software whose existence makes every future project cheaper. It is the reusable, well-tested, portable foundation that lets you start each new product halfway up the stack instead of at the bottom. Where technical debt charges interest, software capital pays dividends. You don’t pay it, it pays you.

Software is Magic

Among all the capital goods an organization can own, software is unique. A machine on a factory floor can run one production line. A software asset can be deployed in every project simultaneously, because copies are free. It is not consumed by use, and it does not wear out from it. If anything, the opposite happens: every project that builds on the asset exercises it, hardens it, and feeds improvements back into it.

This is why the economics of software capital are so extraordinary. Building a high-quality foundation once is genuinely expensive. But that cost is incurred once, while the returns are collected on every project, forever, at zero marginal cost. No physical asset compounds like this.

Not All Code is Capital

There is a trap in this argument, and it is worth naming. As we argued in Less is More, every line of code is a liability by default. It must be read, understood, maintained, and maintained. So software capital cannot simply mean “more code lying around for later”. A junk drawer of copy-pasted snippets and half-finished utility modules is not capital. It is unacknowledged debt masquerading as an inventory.

Code qualifies as capital only when its reuse value exceeds its carrying cost. In practice that means a sharp abstraction boundary that hides implementation and reveals intent. It means a test suite that proves its correctness, so users of the asset can trust it without re-verifying it. It means documentation and an interface designed for consumers other than its original author. And it means portability.

What Software Capital Looks Like in Practice

In embedded development, the asset side of the ledger has a very concrete shape.

A hardware abstraction layer that keeps your application code vendor-neutral is capital: when a chip is discontinued or unobtainable, the port to another vendor is a contained task instead of an existential crisis. Driver and protocol libraries that are tested independently of any product are capital. A test harness that runs your firmware logic on the host, without hardware in the loop, is capital. So are CI pipelines, build system templates, and project scaffolds that let a new product repository go from zero to compiling, testing, and flashing in an afternoon.

This is precisely the reasoning behind our modern embedded template library (metl): implementation details move into a heavily tested lower layer, application developers work against stable abstractions, and porting between microcontroller families stops being a rewrite. Every project we build on it collects the dividend, and every project hardens the asset further.

The Dividends

Framed economically, the returns on software capital fall into a few categories.

Velocity. Each project starts further up the stack. The undifferentiated groundwork is already built, already tested, already paid for, so engineering time flows into the features that make the product distinct.

Quality. A battle-tested foundation carries its defect history with it. Bugs fixed once stay fixed everywhere, and new products inherit years of hardening on day one.

Optionality. Portable, standards-based assets keep your choices open: of silicon vendor, of toolchain, of architecture. As we argued in Stay Free, that freedom is negotiating power, and negotiating power is worth real money.

People. Well-bounded abstractions reduce the cognitive load on every engineer, and new team members become productive against clean interfaces long before they understand every implementation detail beneath them.

Enterprise value. For a product company, software capital is not a metaphor. A reusable, tested, portable codebase is an asset that survives due diligence, where a debt-ridden one is a discount.

There is also a distinctly current dividend. AI-assisted development amplifies whatever foundation it operates on. Sharp abstractions give generated code clean seams to fit into, and a rigorous test suite is exactly the guard-rail that makes machine-written code safe to accept. Software capital is the asset that AI multiplies; without it, AI merely helps you take out loans faster.

How to Build Software Capital

Harvest, don’t speculate. The graveyard of internal frameworks is filled with assets built in anticipation of needs that never materialized. Capital is extracted from real, repeated work: when the same problem appears for the third time, that is your signal to invest in the abstraction.

Hold a product-grade bar. An internal asset without tests, documentation, and a deliberately designed interface is not capital, it is debt wearing a nicer name. If it is worth reusing, it is worth engineering like a product.

Denominate it in industry standards. Capital held in a proprietary currency devalues at the vendor’s convenience. Assets built on standard languages, standard build systems, and open toolchains keep their worth across projects, platforms, and decades.

Budget for maintenance. Give shared assets an owner and explicit time. Depreciation is only a problem for capital nobody is responsible for.

Let debt repayment mint capital. This is the deepest connection between the two sides of the ledger. When you refactor away debt, don’t just aim for zero: extract the reusable core, put it under test, and give it a clean interface. The same effort that removes a liability can create an asset.

Conclusion

Technical debt tells you what your past shortcuts cost. It says nothing about what your past investments earn. Teams that only ever fight debt are running hard to stand still, and the best they can hope for is a clean slate.

The goal of a project is never just a product that ships. Every project should leave something behind that makes the next one cheaper, faster, and safer. Pay down your debt, by all means. But don’t stop at zero: build software capital, and let it pay you.