The software dollar nobody can find: tracing spend through half-built releases

Ask a roomful of engineering directors what their last abandoned software release cost, and you'll get a wall of shrugs. Nobody tracks the dead releases the way they track the live ones. Nobody wants to. The accounting lives in three different systems, the JIRA tickets were closed under a sprint that was itself canceled, and the engineers who built the abandoned feature have long since moved to a new team. By the time finance asks where the money went, the trail is cold.

This is the corner of the software economy nobody puts on a quarterly slide. The conversations I keep having with CTOs at mid-market companies all arrive at the same uncomfortable number: somewhere between a quarter and a third of every software budget is spent on work that never reaches a customer. Some of that is healthy — prototypes that teach you what to build next. A lot of it is not. It is scope churn, misaligned priorities, and the slow hemorrhage of feature work that loses its champion mid-build.

The arithmetic of half-built releases is harder than it looks

When a software initiative dies before launch, the cost isn't just the engineering hours. It includes the infrastructure that was provisioned and never decommissioned, the third-party API seats that were paid for a quarter in advance, the design contractors who invoiced against a milestone that quietly slid off the roadmap, and the opportunity cost of the engineers who could have been shipping something else. Few organizations measure all of it. Most measure none of it.

The 2024 IT Spending Benchmark from Gartner put global enterprise software spend at just over $1 trillion. Even using a conservative estimate — that 25% of in-flight software work gets canceled or deprioritized before it ever touches a customer — that implies a quarter of a trillion dollars a year evaporates inside half-finished builds. That's larger than the GDP of South Africa. And unlike most large pools of capital, almost none of it is visible on a P&L statement.

Why the spend hides in plain sight

Software accounting is organized around what shipped, not what was tried. Capitalized software development costs under ASC 730 only kick in once a project crosses a defined technical feasibility threshold, which means the early — and usually the most abort-prone — stages of a release sit in operating expense, buried inside engineering payroll or professional services. By the time the CFO sees the line item, it has already been laundered into "salaries" or "consulting."

The other hiding place is the cloud bill. A feature team spins up a staging environment in a new region to test latency for a market they ended up not entering. The environment runs for eleven months. Nobody on the engineering side owns the teardown because the team that provisioned it was restructured in August. The bill keeps paying itself until a FinOps analyst — if you're lucky enough to have one — notices an anomaly during a quarterly review. Most companies don't have that analyst. The money continues to leak.

What gets measured, in fact, gets managed

The teams I've watched actually claw this problem back share three habits. First, they tag every software initiative at intake with a cost category that survives sprints, restructures, and renaming conventions. Second, they publish a quarterly "software graveyard" report: features canceled, dollars sunk, reasons given. The report is uncomfortable the first two times. By the third, the organization starts self-policing because nobody wants to be the team whose abandoned release leads the next slide deck.

Third — and this is where most engineering orgs still stumble — they treat the cost of a half-built release as a real number that goes into the next prioritization conversation. Not as a vague sense of "we burned some time on that," but as a line item. When the next product owner proposes a major initiative, the conversation starts with: what is the most we've spent on a release that didn't ship, and what did we learn from it? That single question has saved some of the operators I've talked to from repeating the same six-month mistake twice.

The hidden compounding cost of architectural rework

There's a second-order financial effect that gets even less attention. When software releases die late in the cycle — past the architecture lock-in — the next team inherits code, schema decisions, and integration contracts they didn't choose. Every future feature built on top of that abandoned foundation pays a tax in the form of workarounds, brittle abstractions, and accumulated technical debt. The original cost of the dead release keeps charging interest, quarter after quarter, in the velocity metrics of the team that comes after.

One engineering director at a fintech I spoke with last quarter put it bluntly: "We stopped measuring our cancellation rate because it depressed the team. Then we couldn't explain why our feature velocity kept falling even though headcount kept rising." The connection — that abandoned releases were quietly reshaping the codebase into something slower to build on — was invisible until they started mapping dead-feature branches to the work that came after them. The pattern emerged within a single quarter of looking.

Where the financial impact actually lives in the org chart

The teams best positioned to fix this aren't engineering, and they aren't finance. They sit between the two — the technical program managers, the FinOps leads, the product operations roles that have started appearing in the org charts of companies that take software unit economics seriously. These are the people who can translate a JIRA ticket into a dollar figure, and a dollar figure into a roadmap conversation.

For executives reading this, the diagnostic is short. Ask your engineering leadership for the cost of your three largest canceled software initiatives from the past eighteen months. If the answer takes more than a working day to produce, you don't have the instrumentation. If the answer comes back and nobody wants to discuss it, you have a culture problem that instrumentation alone won't fix. Both deserve attention before the next budget cycle locks in.

What the best operators do differently

The pattern across companies that have reduced their dead-release rate is surprisingly consistent. They cut scope at intake, not at delivery. They assign a named owner to every initiative whose removal would cause a public reorg, and they pay that owner to kill bad projects early, not to defend them. They publish a cost-per-cancellation number, and they make that number visible to the people doing the canceling.

None of this is exotic. None of it requires a new platform or a new methodology. What it requires is treating software spend with the same rigor that capital expenditure gets in a manufacturing business — knowing what you bought, whether it's producing, and what to do with the inventory when it isn't. That rigor is rare. The companies that adopt it tend to look, two years later, like they have a quieter engineering org and a faster product roadmap. The connection is not a coincidence.

For teams that want to go deeper on the mechanics of tracing software spend through abandoned releases — and on the tooling stack that makes the audit tractable — the deep-dive library at osmosis.agency has some of the clearest technical explainers in the space.

The companies that figure this out in the next two years will quietly compound the gap against the ones that don't — because every dollar that stops leaking out of an abandoned release is a dollar that funds the next one that ships.

Explore the practical implications for your business in our implementation resources.

Review the next steps in the business growth guide.