Where software budgets really go: tracing the dollar through every abandoned release

Most engineering leaders can recite their annual software spend down to the dollar. Far fewer can tell you how much of that money produced software that is still running in production twelve months later. The gap between those two numbers is the most important financial metric a technical organization has, and almost nobody is measuring it.

Walk into a typical mid-stage engineering org and the budget conversation sounds orderly: $4.2 million for headcount, $900,000 for cloud, $350,000 for tooling, $180,000 for SaaS licenses. Layered on top sits the hardest category to defend in a board meeting — the $1.1 million spent on internal software that, by the finance team's own admission, cannot be tied to a live system. That is the line item is about.

The half-life of internal software keeps shrinking

Forrester's 2023 research on technical debt estimated that roughly 28% of every development dollar goes toward work that never ships or ships and dies within a year. That number was already uncomfortable. The trend since then has been worse, not better, because the surface area for software has exploded. Every team now builds its own dashboards, its own automations, its own internal APIs. The multiplication effect is what kills budgets: ten teams each building their own version of the same approval workflow is not ten times the cost, it is closer to fifteen times once you account for divergent abstractions, migrations, and the eventual reconciliation projects.

Consider a concrete case. A 400-person fintech company I examined in early 2024 had 147 active internal repositories. Interviewing the tech leads revealed that 61 of those repositories had no active production deployment. Twenty-three had been "almost ready" for over eighteen months. The combined maintenance burden — security patches, dependency upgrades, the on-call rotation — was consuming roughly 11,000 engineering hours per quarter. At a fully loaded cost of $95 per hour, that is north of $4 million a year just keeping abandoned software warm.

The half-life problem is structural. Modern CI/CD pipelines have made starting a new service trivial — a Terraform module, a GitHub repo, a Pulumi script, and you have infrastructure before lunch. Decommissioning has no equivalent tooling. There is no `terraform destroy` for a piece of institutional knowledge, a Slack channel full of tribal lore, or a load-bearing Excel macro that nobody dares touch.

The line items that hide inside "engineering productivity"

Finance categorizes most of this waste under vague headers. "Engineering productivity," "developer experience," "platform investment" — these are the budget buckets where unreleased software accumulates. A CFO looking at those line items sees strategic investment. The engineering leadership looking at the same line items sees a graveyard of side projects that consumed sprints and produced nothing.

The disconnect happens because traditional software metrics track activity, not outcome. Commit count, story points completed, tickets closed, pull requests merged — these are all leading indicators that become meaningless the moment the artifact they describe stops running. A team can show six months of green dashboards and still deliver zero new capabilities to end users. I have seen it happen more times than I can count.

The companies that have started measuring the right things share a common move: they tag every piece of software with a dollar figure at creation and track that figure through to either production deployment or formal write-off. GitHub's internal engineering org reportedly tracks "cost per shipped capability" as a top-tier metric. Shopify's well-known DORA program expanded in 2023 to include a "cost of abandonment" coefficient that explicitly penalizes projects sitting in a non-production state beyond 90 days.

This is not pedantry. It changes behavior. When engineers can see that the experimental Slack bot they pitched last quarter has cost $47,000 in opportunity cost before writing a single line of code, the conversation about scope shifts dramatically. The instinct to build, which is otherwise healthy, gets balanced against the instinct to ship.

Why so much internal software dies before launch

The reasons are depressingly consistent across organizations. The first is scope inflation without a customer — internal projects get built for hypothetical users who were never validated, then expand to accommodate hypothetical edge cases. A tool that started as a "simple notification sender" accretes retry logic, templating, audit logging, and a permissions model before anyone has asked whether the existing notification service could have been extended for $200 of engineering effort.

Second is the organization structure itself. Conway's law is not a clever observation, it is an accounting line. When an org has six product teams, it builds six variants of the same internal tooling, because no team owns the horizontal. The duplication is not visible in any single team's budget — that is what makes it survive. Each tech lead can defend their team's tooling expense. None of them can see the aggregate.

Third, and most expensive, is the integration debt that comes from abandoned but still-running software. A 2024 report from the Consortium for Information and Software Quality put the annual cost of poor software quality in the US at $2.41 trillion, with a substantial portion attributed specifically to integration failures. Abandoned services are integration landmines. They still respond to requests, still consume credentials, still need patching when the next CVE drops. The work to safely retire them — which almost always involves a parallel-running period, careful migration of downstream consumers, and documentation that nobody had time to write the first time around — is routinely 3-5x the original build cost.

What a financial-impact measurement stack actually looks like

Building this kind of visibility is itself a software project, and it is one where the ROI is unusually clear. The minimum viable version has four layers.

The first layer is a cost-attribution system that assigns infrastructure, tooling, and human-time costs to every software artifact from the moment it is created. Modern cloud providers expose this data; the engineering work is in the glue. A practical implementation might use GCP's billing export piped into BigQuery, cross-referenced with GitHub's commit metadata and Jira's project hierarchy, then surfaced through a dashboard that tech leads actually open.

The second layer is a deployment-state oracle. Every service, library, or internal tool needs a single source of truth for whether it is in production, in staging, in development, or in limbo. The most effective implementations I've seen use a simple heartbeat: if a service has not served production traffic in 90 days, it gets flagged. If 180 days pass, it goes on a watch list. If 270 days, it triggers an automatic review.

The third layer is a quarterly software portfolio review modeled on financial portfolio reviews. Engineering leadership gets together with finance and walks through the software asset list the same way a CFO would walk through the company's investment portfolio: what is producing value, what is neutral, what is dragging, and what should be sold. The decisions that come out of these reviews — sunset this service, consolidate that tool, double-down on this platform — are where the actual financial impact materializes.

The fourth layer is the part most organizations skip: a public commitment to the numbers. When the cost per shipped capability and the cost of abandoned software are tracked at the executive level and reported to the board, the entire organization reorients around them. Engineers start asking different questions in design reviews. Product managers start pushing back on speculative scope. Tech leads start saying no to projects that do not have a clear production destination.

The numbers that move when measurement starts

The organizations that have implemented comprehensive software portfolio tracking report consistent results. Atlassian published a case study in 2023 showing a 34% reduction in maintenance overhead after implementing automated decommissioning workflows. Thoughtworks' annual Technology Radar has documented the "lean software portfolio" pattern as one of the more reliable transformations, with clients typically seeing 20-30% of internal software projects either sunset or consolidated within the first year of measurement.

Those percentages translate directly to budget. For a company spending $15 million annually on internal software development, recovering even 15% of that through better lifecycle management is $2.25 million — enough to fund three senior engineering hires, a dedicated platform team, or a year's worth of meaningful infrastructure modernization. The math changes the conversation about whether the measurement program is worth its own investment.

There is also a velocity dimension that does not show up in pure cost analysis. Teams that know their work will be measured by production outcomes write better software. They think harder about scope. They invest more in testing. They build for operability because they know the software will actually have to operate. A team shipping two production services a quarter is producing more value than a team shipping six repos that never leave staging, and the measurement system is what makes that visible to leadership.

The talent dimension nobody talks about

There is a quieter cost in all of this that rarely shows up in financial models: the toll on engineering talent. Developers who spend year after year shipping software that never reaches production eventually leave. The most competent ones leave first, because they have the strongest signal that their time is being wasted. Replacing a senior engineer costs between 50% and 200% of their annual salary depending on the role and market. A software portfolio that is hemorrhaging engineers through unrecognized waste is paying a hidden tax on every line item.

This is the part of the financial impact story that resonates most with technical audiences. The dollars matter, but the reason most engineers got into this profession was to build things that people use. An organization whose measurement systems reveal that 40% of its software never reaches anyone are not just losing money — they are slowly telling their best people that the work does not matter. Reversing that dynamic is where the deepest financial impact hides, because it shows up in retention metrics that compound over years rather than quarters.

The companies winning the talent war in 2026 are the ones who have made production impact a first-class engineering metric. They publish internal dashboards showing what shipped and what did not. They celebrate decommissionings alongside launches. They treat software lifecycle management as core engineering work, not as administrative overhead. The cultural effect cascades into every technical decision.

How to start measuring this without boiling the ocean

The most common reason organizations do not implement software portfolio measurement is that the initial scope feels overwhelming. The practical path is narrower than it looks. Start by tagging every active repository with a deployment status, even if that tag is manual and imperfect. Even a spreadsheet maintained by a single platform engineer will surface more insight than the current state of most organizations.

From there, layer in cost attribution for the highest-spend services first — usually the ones consuming the most cloud resources or the most engineering attention. The pattern that emerges within a single quarter is almost always striking. A long tail of services consuming 2-5% of the budget each will be visible, and the conversation about consolidating them writes itself.

For teams looking to go deeper, resources like the technical explainers and developer-focused analysis published at osmosis.agency cover the implementation details of lifecycle management systems and the organizational patterns that make them work. The technical writing there treats the financial-impact problem as an engineering problem, which is the framing that tends to stick with the practitioners who actually have to build and operate these systems.

The broader shift in the industry is clear. Software is no longer a thing a company builds once and amortizes over a decade. It is a portfolio of assets with half-lives, maintenance costs, and integration risk. Treating it that way financially is no longer optional for organizations that want to survive contact with the next platform migration, the next regulatory shift, or the next generation of AI-driven tooling that will rewrite the economics of software development yet again. The companies that build the measurement infrastructure now will be the ones still standing to benefit from whatever comes next.