Solution · Delivery economics

Software delivery profitability: how to measure it, and how to improve it.

Most software teams track speed. Very few track what a delivered unit of value actually costs — and where that cost quietly grows. This page explains both.

Definition

Value delivered ÷ the full cost of delivering it.

Not just salaries and tooling. The full cost includes everything the delivery system consumes to turn an idea into working, maintained software: rework, review time, coordination, waiting and the cost of delay when dates move.

Two teams with identical headcount and identical velocity can have very different profitability. The difference is rarely visible in a sprint report. It shows up in the P&L — months later, as margin that should exist and doesn't.

Working definition
value ÷ fully loaded cost

Where "fully loaded" includes rework, review, coordination and delay — the costs most dashboards never show.

The leaks

Four places software margin quietly disappears.

01

Rework

Defects, unclear requirements and late changes mean the same value is paid for twice — or three times. In many teams rework silently absorbs 20–40% of capacity before anyone measures it; yours may differ — the point is most teams have never calculated it. How to calculate it.

02

Review overload

Every change needs someone senior enough to catch what's wrong with it. AI-assisted coding often amplifies this: generation gets cheaper, verification gets more expensive, and the bottleneck moves to your most costly people.

03

Cost of delay

When dates move, revenue moves with them — and coordination cost grows while everyone waits. Unpredictable delivery has a price, and it compounds.

04

Invisible coordination

Dependencies, approval queues and status rituals consume hours that never appear in any estimate. They are paid for all the same.

Measurement

The metrics that expose delivery profitability.

Operational metrics tell you where the system leaks. Economic metrics tell you what the leak costs. You need both — and a baseline before you change anything.

LayerMetricWhat it tells you
OperationalRework rate (% of capacity)How much of what you pay for is paid for twice
OperationalReview time per changeWhere senior capacity is being consumed
OperationalDelivery predictability (committed vs delivered)Whether dates can be trusted — and planned around
EconomicCost per delivered unit of valueWhat a feature or release actually costs, fully loaded
EconomicProfit per delivered hourWhether improvement is reaching the P&L
Worked example · Illustrative

A simple model you can run on your own numbers.

The figures below are deliberately round and illustrative — not a client case. Replace them with your own payroll and capacity data.

Team of 10 engineers, fully loaded cost NZ$1.8M/year (~NZ$150k/month).
Measured rework absorbs 25% of capacity → ~NZ$37,500/month buys nothing new.
Reducing rework from 25% to 15% recovers ~NZ$15,000/month — roughly one full engineer, without hiring.
The same logic applies to review time and delay: measure the leak, price it, then decide where to intervene.

This is why "the team feels faster" is not a business result. A baseline and a priced leak are.

Measured outcome · Client-approved
€7M → €9M

A €7M software consultancy grew to €9M in 12 months while improving profit per delivered hour by 15% — through OKRs, delivery discipline and AI-enabled workflows. Every number we publish has a baseline, a timeframe and a client who approved it.

How this becomes an engagement

Baseline first. Intervention second. Proof always.

The free Diagnostic maps your top profitability leaks and your AI maturity baseline in 45 minutes. If there is real leverage, a fixed-price Pilot Sprint tests it against that baseline in 4–6 weeks. If the pilot doesn't beat the baseline, we recommend not scaling — in writing.

FAQ

Questions leaders ask about delivery profitability.

The relationship between the value a team delivers and the fully loaded cost of delivering it — including rework, review time, coordination and delay, not just salaries. A team can be busy, fast and still unprofitable.

Establish a baseline: cost per delivered unit of value, rework as a percentage of capacity, review time per change, and delivery predictability. Then track profit per delivered hour over time. Without a baseline, any claimed improvement is unverifiable.

No. Productivity measures output per person; profitability measures whether output becomes margin. More code, faster, can reduce profitability if it increases rework, review burden or technical debt downstream.

Not by itself. AI shifts cost from writing code to reviewing and correcting it. Whether the net effect reaches the P&L depends on workflows, quality standards and measurement — which is exactly what guardrails are for.

A baseline takes one to two weeks. Measurable movement in rework, review time or predictability is typically visible within 30–60 days if the constraint has been identified correctly.

Author

Nicolás Espinosa — Founder, Optimum Agile. Former Director of Product at PikPok and Senior Delivery Manager at Trade Me; postgraduate specialisation in AI Product Management (Duke University). Based in Auckland, working with software companies across New Zealand and Australia on delivery economics and disciplined AI adoption.

Last updated: July 2026

Find out where your delivery is leaking margin. In 45 minutes. Free.

One working session with Nicolás. A written 30-day roadmap, yours to keep either way.