Cost Per Shipped Feature: A Better Metric Than Hourly Rate
Last updated November 2026
To get cost per feature, add up everything it took to deliver the work (vendor fees, the time your own people spent, and fixes after release) and divide by the number of features still working in production 90 days after they shipped. It is a better yardstick than hourly rate because it bills each team for the rework, coordination and failed work that a rate hides.
Why is hourly rate a poor way to compare software teams?
An hourly rate prices time, but what you are buying is software that works. The rate describes the input and says nothing about what comes out. On paper the spread looks like it settles the question. The Accelerance 2026 rate report lists senior developers at $31 to $41 an hour in Asia, $60 to $75 in Latin America and $64 to $76 in Europe, a gap of roughly two to one. That gap vanishes the moment one team needs double the hours, double the review from your staff, or a second attempt at what it handed over.
Counting output is no longer a safe stand-in either. AI tools made code cheap to write without making it any cheaper to get right. Meta is the plainest public example. According to TNW’s summary of Reuters reporting from August 2026, a June post by Meta’s CTO said code changes to internal platforms and infrastructure were up 220% year on year, while new or upgraded features reaching users were up 36%. The same report said major technical and security incidents rose 40% and the time spent firefighting them rose 70%. Meta declined to comment on the internal data, and because the figures measure different things they do not reduce to a neat ratio. What they do show is why a buyer should count what reached users and what it cost to keep it there.
How do you calculate cost per feature in software development?
Measure over a quarter. A month gives you noise, and by the end of a year it is too late to do anything about the result. Add up the five lines below, then divide by the features that pass the test described in the next section.
- Team cost. Vendor invoices, or the fully loaded cost of employees. Our pillar on what senior software engineers actually cost in 2026 works this out from federal data and arrives at about $151 per available hour for a $170,000 hire.
- Your side of the work. The hours your staff put into specifying, reviewing and unblocking, priced at your own loaded rate. No vendor rate covers this line, and it is usually where a cheap quote turns expensive.
- Tooling tagged to the work. AI tokens, CI compute and environments, wherever you can attribute them.
- Post-release fixes. Hours over the next 90 days spent on bugs, rollbacks and incidents that trace back to the work.
- Failed work. Features dropped halfway through, or shipped and later pulled. The VirtusLab Visdom guide to cost per feature says these belong in the total, and it is correct: you paid for them.
Work at the level of the feature, not the pull request. VirtusLab points out that a single feature often spans 20 to 100 PRs, and cost per PR leaves out design, product and stakeholder time. If you do not track time, its proxy will do: calendar days from kick-off to production, multiplied by the number of people actively working, multiplied by a utilization factor of 70% to 80%.
What should count as a shipped feature?
Whether the metric tells the truth depends on this definition, and most guides skip over it. A feature only counts when all four of the following hold.
- Real users have it switched on. Code sitting behind a flag at 0% is inventory, not delivery.
- Someone outside the team that built it signed it off against criteria written before work started.
- Within 90 days it was not rolled back, removed or reopened because of a defect.
- From the user’s point of view it is one feature, no matter how many tickets it was broken into.
The 90-day window is our planning choice, not an industry standard. It gives real usage enough time to hit the edge cases. The price is a lag of one quarter, so report shipped and durable counts next to each other. If you want an earlier warning, track two measures from the DORA metrics guide: change fail rate, the ratio of deployments that need immediate intervention, and deployment rework rate, the ratio of deployments that are unplanned and happen because of a production incident. When either one starts climbing, your durable count is usually about to fall.
How does cost per feature change a vendor comparison?
Below is a single quarter with two hypothetical teams. Every figure is illustrative, not survey data. Team A has twice as many engineers at a third of the rate. In both columns your staff cost $151 an hour.
| Line item | Team A: 4 engineers at $40/hr | Team B: 2 engineers at $120/hr |
|---|---|---|
| Vendor invoices, 480 hours each | $76,800 | $115,200 |
| Your staff time | 300 hours, $45,300 | 100 hours, $15,100 |
| Post-release fixes at vendor rate | 300 hours, $12,000 | 50 hours, $6,000 |
| Total cost | $134,100 | $136,300 |
| Features shipped | 12 | 9 |
| Features durable at 90 days | 7 | 8 |
| Cost per shipped feature | $11,175 | $15,144 |
| Cost per durable feature | $19,157 | $17,038 |
Judged on rate, Team A looks three times cheaper. Judged on cost per shipped feature, it is still ahead by about 26%. Judged on cost per durable feature, Team B comes out about 11% cheaper. Change the inputs and the result could flip, and plenty of lower-rate teams will win on this measure. A rate cannot tell you which situation you are in. This table can.
Is there a cost per feature software benchmark you can trust?
None that we would put in front of a board. The ranking guides we read give formulas, not numbers. VirtusLab offers illustrative figures of roughly $2,000 for UI polish and $40,000 for a payment integration, a 20-fold spread within one product. An average across companies would tell you even less, and DORA cautions that comparing metrics between vastly different applications can mislead.
Instead, build your own baseline: size each piece of work before it begins, and only compare within the same tier.
| Tier | Rule of thumb | Example |
|---|---|---|
| Small | One service, no schema change | New filter on an existing report |
| Medium | Two or more services, or a schema change | Role-based permissions on an existing module |
| Large | New external integration, new data model or regulated data | Payment provider integration |
Two quarters in, you will have a median for each tier. VirtusLab suggests looking into anything that comes in at twice the benchmark. That is a sensible trigger, provided the question stays “why was this expensive” rather than “who do we blame”.
How do you stop cost per feature being gamed?
Once money rides on a single number, people start managing the number. DORA’s guidance fits: do not turn metrics into goals, do not lean on one metric alone, and do not use them to set teams against each other. Look out for four moves.
- Splitting. One feature is broken into five to push the count up. The user-view rule above stops this.
- Cherry-picking. The easy work gets picked up and the hard work slides. Tiers make it visible.
- Cost shifting. The vendor’s hours go down while your staff’s hours go up. Line 2 catches this, which is why it has to be measured on your side.
- Skipped quality work. Tests and review get dropped to hit the number. VirtusLab’s rule deals with it: never report cost per feature without incidents per merged change and firefighting hours alongside it. As it puts it, a throughput-only report is “not measuring, it is selling.”
Apply the metric to teams and vendors across quarters. Point it at individual engineers and all it measures is who got handed the easy tickets.
How do you put cost per feature into a vendor contract?
Paying per feature is rarely necessary. What you need is the reporting, and the power to act on what it shows.
- Put your definition of a shipped feature into the statement of work.
- Ask for weekly hours reported by feature, not by person or by ticket.
- Say who signs acceptance, and make sure it is someone outside the vendor’s team.
- Spell out who pays for defects found in the 90 days after release.
- Keep the exit clause short.
Our guide to software development pricing models shows who carries overruns under each structure, and how to read a proposal for hidden costs walks through the clauses that push lines 2 and 4 onto your budget.
A monthly fee keeps the arithmetic simple. Delivery Pods start at $15K per month on 30-day notice, so one quarter at the starting price puts $45,000 on the invoice; you add your own lines and divide. PULSE telemetry reports 400+ data points a week, giving you data to check the count against, and the notice period means a bad number can turn into a decision within the same quarter.
Frequently asked questions
What is cost per feature in software development?
It is everything you spent delivering work in a period (team cost, your own staff time, tooling, post-release fixes and failed work) divided by the features that reached users and kept working. It tells you what a working feature costs rather than what an hour costs.
Should cost per feature replace hourly rate?
Drop it as the deciding metric but keep it as an input. You still need the rate to work out team cost and to negotiate. It just should not pick the team you hire, since it tells you nothing about the hours required, the review load or the rework.
Do AI coding tools lower cost per feature?
Not on their own. They make writing code cheaper, but review, rework and incident time can go up. If staff review hours and post-release fixes grow faster than the durable feature count, the extra AI output has made each feature more expensive, even while commit volume rises.
Book a Code Review
When you are comparing quotes, the piece usually missing is how many hours the work will actually take in your codebase. A senior engineer who reads the code can tell you, and that turns a rate comparison into an estimate of cost per feature. Our engineers average 10+ years of experience. Book a Code Review.