Software Delivery Benchmarks: Our 2026 Numbers
Our full-year software delivery benchmarks: cycle time, defect escape rate and cost per feature, with definitions so you can audit your own vendor.
Founder, Viithiisys
What does this software delivery benchmarks report contain?
This page contains no full-year 2026 figures. It sets out how we define cycle time, defect escape rate and cost per shipped feature, and the reporting rules we hold ourselves to. We publish the numbers only after the year closes.
Software delivery benchmarks only help a buyer when the definitions are public before the numbers are. Publishing the method first means nobody can say we chose the definitions after seeing the results. We will report the figures once the year closes and the data has been reviewed.
We start here because of how most delivery claims are made: a single average, no definition, no denominator. This page is our attempt to do the opposite.
What metrics does it cover?
It covers three engineering delivery metrics that a buyer can ask any vendor for:
- Cycle time: how long a scoped piece of work takes to reach production.
- Defect escape rate: how many defects get past testing into production.
- Cost per shipped feature: what finished, accepted work costs once waste is counted.
Who should read it?
Read it if you are choosing between building in-house and hiring a partner, or if you already have a vendor and cannot tell whether they are fast. If you want the track record behind our work, our case studies show the projects we deliver.
Method and definitions
Every metric below is defined before any number appears: what starts the clock, what stops it, and what is excluded. A benchmark without those three answers cannot be compared with anyone else's. These are the three core definitions:
- Cycle time: time from the first commit on a scoped work item to that item running in production.
- Defect: any behaviour that deviates from the accepted specification and needs a code change.
- Feature: one user-visible capability with written acceptance criteria agreed before work starts.
We exclude discovery-only engagements and projects paused by the client for more than 30 days. Paused work stops the clock, so including it would measure the client's calendar, not our delivery. Every exclusion will be listed alongside the results.
| Metric | Clock starts | Clock stops | Reported as |
|---|---|---|---|
| Cycle time | First commit on a scoped work item | Item running in production | Median, by project type |
| Defect escape rate | Defect is logged | Defect is classified as pre-release or production | Percentage of all defects |
| Cost per shipped feature | Delivery period opens | Period closes | Total cost divided by accepted features |
How do we define cycle time?
Cycle time is the time from the first commit on a scoped work item to that item running in production. It is narrower than lead time, which starts when a request is made.
Microsoft documents the same distinction in its Azure DevOps cycle time and lead time guidance.
We report the median, not the mean. One stalled item waiting on a client's legal review can distort an average badly, while a median stays close to what a typical item experiences.
How do we define a defect and a feature?
A defect is any behaviour that deviates from the accepted specification and needs a code change. A change request is not a defect, even if the client is unhappy.
A feature is one user-visible capability with written acceptance criteria agreed before work starts. Splitting a feature afterwards to flatter the count is the commonest way cost per feature gets gamed, so we fix the unit up front.
What drives cycle time in each project type?
Cycle time depends heavily on the kind of work being done. A fixed-scope MVP and a legacy modernisation are different jobs, so a single blended number would hide the pattern. When we publish, we will report a separate median for each type.
| Project type | What mostly drives cycle time | What to watch when comparing |
|---|---|---|
| Moonship MVP (fixed scope) | Scope discipline, since the scope is fixed up front | Whether scope really stayed fixed |
| Web application | Review and release process | Work items of very different size |
| Mobile application | App store review and device testing | Store review time counted or not |
| AI and LLM projects | Evaluation and data quality work | Experimental work counted as delivery |
| System modernisation | Legacy constraints and hidden dependencies | Discovery effort left outside the clock |
How will we show sample sizes?
The Moonship MVP page explains what the fixed scope covers. When we report that type, we will check whether scope actually stayed fixed rather than assume it.
Small sample sizes matter. A median over three projects is an anecdote, so we will show the project count beside every median and let you judge how much weight it deserves.
What is our defect escape rate?
Defect escape rate is the share of all defects that reach production instead of being caught earlier. It measures how well testing works, not how few bugs a team writes.
Why can a low number mislead?
A team that logs few defects in testing will show a poor escape rate even with good code. A team that never logs pre-release defects will show a flattering one. The rate is only honest when pre-release defects are recorded as diligently as production ones.
Our commitment is to log every defect found in review, automated tests and manual QA, and to classify them the same way. Our QA and testing service is where that practice applies.
Why do late defects and severity matter?
The US National Institute of Standards and Technology examined the cost side in its study of the economic impacts of inadequate software testing infrastructure. It estimated the annual cost of inadequate testing to the US economy at about $59.5 billion in 2002. The finding that matters to a buyer is that fixing a defect late is more expensive than catching it early.
Raw escape rate also hides the cases that hurt. So we will report the share of escaped defects that were severity one, meaning data loss, a payment failure or an outage, next to the headline rate. A low headline rate with several severity-one escapes tells a different story from the same rate made of cosmetic issues.
How do we count cost per shipped feature?
Cost per feature is total delivery cost for a period divided by features that reached production and passed acceptance. Vendors rarely publish it, because it exposes how much spend never turns into accepted work.
We define the two sides of the fraction strictly:
- Numerator: engineering, QA, design, project management and rework, including features started and abandoned.
- Denominator: only features that passed written acceptance criteria. A half-built feature does not count, however much was spent on it.
Abandoned work stays in the numerator because a vendor who counts only finished work is hiding waste. That is the main reason the metric is useful for comparing vendors.
A note on price: This page states a method, not a cost figure, and any figure we later publish describes past delivery, not a quote. Work is scoped per project after a discovery call. The commercial shape is a fixed scope or a fractional basis, depending on the engagement. Treat cost per feature as a way to test a vendor's discipline, not to predict your bill.
How will we report where we got worse?
A benchmark report that lists only improvements is marketing. When the full-year figures are published, every metric will be shown with its year-on-year change in either direction, and any metric that moved the wrong way gets its own section.
A delivery benchmark that has no section for where the vendor got worse is a brochure.
What will each regression section contain?
Each section will answer the same three questions:
- Which metric worsened, and by how much compared with 2025?
- What caused it, with evidence rather than a guess?
- What did we change in response, and on what date?
The usual candidates for any delivery team are growth in scope per project, onboarding new engineers, and rising client-side approval delays. We will state which applied to us. A regression with no response is just a trend, and clients deserve to see the response alongside the problem.
How do you compare software delivery benchmarks from different vendors?
Ask your vendor for the same three metrics with the same definitions, over a full year, with excluded projects listed. A vendor who cannot produce them does not measure them, and what is not measured is not managed.
What should you ask a vendor for?
Use this list, which applies to delivery benchmarks from any firm:
- How does cycle time start and stop, and is it a median or a mean?
- How is a defect classified, and are pre-release defects logged?
- What counts as a feature, and who agreed that before work started?
- Which projects were excluded, and why?
- What got worse last year?
How do the DORA measures fit alongside these metrics?
The DORA research programme gives you four delivery measures to compare against: lead time for changes, deployment frequency, change failure rate and failed deployment recovery time.
Our cycle time definition is intended to line up closely with lead time for changes, though we will state any differences when we publish. Defect escape rate is a different cut of the same quality question that change failure rate asks. Use the DORA measures alongside the three above, not instead of them.
Can a fractional CTO help you read vendor numbers?
If nobody on your side can read these metrics, a fractional CTO can sit between you and the vendor. Our CTO-as-a-Service works on a fractional basis for exactly this reason. Our engineering sits in Mohali, with an office in Markham, Ontario, so reviews can run across US, UK and Canadian working hours.
Test your own delivery against these definitions
Definitions are only useful if they are applied. To see how your current delivery looks under the same definitions, start with the broken workflow assessment and bring your last two quarters of delivery data, even if it is messy.
We will tell you which of these numbers you can calculate and which you cannot, and that gap is usually the most useful finding. You can also check the people behind our work on our company page.
FAQ
- What are good software delivery benchmarks?
- The most widely used reference is the DORA research programme, which tracks lead time for changes, deployment frequency, change failure rate and recovery time. A good benchmark is one measured with a stated definition, over a full period, on comparable work. A bare average with no definition tells you nothing.
- How do I measure cost per feature?
- Divide total delivery cost for a period by the number of features that reached production and passed acceptance. You must define what counts as a feature before the work starts, otherwise the denominator drifts. Exclude abandoned work from the count but keep its cost in the numerator.
- What is a defect escape rate?
- Defect escape rate is the share of defects found after release rather than before it. Divide production defects by all defects found, in testing and in production, over the same period. A low rate means testing catches problems early, provided the team logs pre-release defects honestly.
- How should I compare agency delivery benchmarks?
- Ask each agency for the same four things: how cycle time starts and stops, how a defect is classified, what a feature is, and which projects were excluded. If two agencies cannot answer all four, their numbers are not comparable, however good they look in a pitch deck.