Amazon Cost to Serve Software (CTS-SW)
Amazon's numbers on developer experience: what it measured, how the savings make a business case, what drives cost down and which metrics it rejects.
Written by
-
Benedikt Stemmildt Founder & Co-CEO
Updated:
Evidence 7
Our position. We hold that the developer-experience floor under the model is the part of the factory that does not compress: the model improves on its own schedule, and the floor it stands on is yours to build. Most agentic tooling a team buys will not outlive the next model generation, while fundamentals that help humans first and agents second will (six investments that outlast the tooling (opens in a new tab)).
Amazon’s numbers support that position with an outcome measured in money rather than in minutes saved (Quantifying the Impact of Developer Experience: Amazon’s 15.9% Breakthrough (opens in a new tab)). Most of the levers behind the reduction are fundamentals such as build, test, review and onboarding, and only two of the eight are AI uses.
What is Cost to Serve Software?
Amazon adapted their retail “cost to serve” metric to software delivery. CTS-SW = total cost of delivering a unit of software. The unit differs by team: deployments for microservices, PR completions for monoliths/mobile apps. This gives a single economic metric that captures the full SDLC, not just velocity.
Key insight: traditional productivity measures (velocity alone, minutes saved, activity-level metrics) fall short because they ignore quality, risk, and availability – and they can be gamed. CTS-SW ties to cost avoidance and ROIC, which is language finance and leadership understand.
What did Amazon measure?
Amazon reports these changes year over year for 2024:
- 15.9% CTS-SW reduction (cost avoidance, not just speed)
- 18.3% increase in weekly production deployments per builder
- 30.4% reduction in human interventions per deployment (automation)
- 32.5% decrease in incident-related tickets per deployment (since 2022)
How do the savings translate into a business case?
Enterprise (software supports the business): 1K developers at $130K each = $130M cost base. 15% CTS-SW improvement = $20M cost avoidance. With $2M solution cost = 10x ROI.
Tech company (software is the product): 400 developers, software = 60% of revenue. 15% CTS-SW improvement = 9 percentage points gross margin improvement. With 15% profit margin = 60% profit boost.
What drives the cost to serve down?
- Streamlining build and test processes
- Improving code review efficiency
- Faster onboarding for new builders
- Centralizing updates and upgrades (reduced toil)
- Safe, easy CI/CD tooling (fewer manual steps, fewer rollbacks)
- Reducing technical debt and common defect sources
- AI-assisted migrations (Java version upgrades via Amazon Q Developer)
- AI-powered knowledge access (Q Business for onboarding, log analysis)
Which productivity measures does Amazon reject?
- Measuring only velocity (ignores quality, risk, availability)
- Calculating “minutes saved” on discrete activities (doesn’t translate to business value)
- Activity-level metrics tied too closely to specific tasks (gameable)
- Siloed teams only optimizing what’s under their direct control
Related
- The DX AI-assisted engineering impact report: DX’s finding that CI waits and approval bottlenecks still cost more time than AI saves.
- The DORA report on AI-assisted development: why platform and developer-experience investment has outsized returns once AI arrives.
- AI productivity studies: METR, Stanford, DORA and Multitudes: the studies that show why minutes saved are the wrong unit.
- Measuring impact: turning a cost metric like CTS-SW into a team’s own outcome measurement.
- The enabling environment: the platform floor a software factory stands on.
Resources
Articles
- Quantifying the Impact of Developer Experience: Amazon’s 15.9% Breakthrough (opens in a new tab) - AWS enterprise-strategy blog post on Cost to Serve Software, Amazon’s metric for the full cost of delivering software, and its 2024 results.