Ask what DO-178C costs and you will hear numbers spanning an order of magnitude, all delivered with confidence. The honest answer is that the multiplier depends less on the standard than on decisions you control — and that the folklore figures come from programmes that made those decisions badly.
This article will not give you a number. It will give you the five things the number actually depends on, the shape of where money goes, and the questions that make a quote meaningful.
Why the folklore numbers are useless
The widely-quoted multipliers — "certification doubles the cost", "Level A costs five times commercial" — share a defect: they average programmes that retrofitted assurance onto finished code together with programmes that built it in. Those are not the same activity. Retrofitting means reconstructing requirements from code, reverse-justifying design decisions nobody documented, and discovering at coverage time that the architecture resists testing. Building it in means writing down what you were going to write down anyway, in a form an auditor can sample.
The first is genuinely expensive. The second is mostly discipline. Averaging them produces a number that describes nobody.
The five drivers
| Driver | How it moves cost | Who controls it |
| Assurance level | Sets objective count, independence staffing, and coverage criterion — the C-to-D boundary is the largest single step | The safety assessment (and architecture) |
| Requirements quality and stability | Every requirement change late in verification re-runs a slice of the programme; unverifiable requirements cost twice | You |
| Reuse and previously developed software | Genuine reuse credit removes whole objective areas; false reuse ("it flew before" without evidence) removes nothing | Partly you, partly history |
| Tool qualification | Qualified tools eliminate manual verification labour, but qualification itself has a price — a make-or-buy decision per tool | You |
| Team experience | A team's first DO-178C programme carries a learning tax that no process eliminates; the second programme is dramatically cheaper | Partly you |
Where the money actually goes
Teams new to the standard assume the cost is paperwork. The actual shape, on programme after programme: verification dominates — typically approaching half the engineering effort at the upper levels once test development, execution, coverage analysis and the independence staffing are counted honestly. Planning and standards are a rounding error by comparison, which is ironic given they determine how expensive everything else becomes.
Schedule: the honest version
The schedule question has the same structure as the cost question, with one addition: certification has gates that do not compress. You can parallelise development, but SOI reviews happen in order, findings take calendar time to close, and the authority's own availability is not yours to schedule. The programmes that blow their dates are rarely slow at engineering — they are surprised by closure time they never budgeted.
Rules of thumb that survive contact with reality: verification takes longer than development the first time, whatever the plan says; SOI finding closure is measured in weeks, not days; and the last five percent of structural coverage takes as long as the first ninety-five if the architecture was not designed for testability.
How to make a quote meaningful
- Fix the level first. A quote that predates the safety assessment is a guess wearing a spreadsheet.
- State the reuse claim precisely. "Based on our previous product" can mean anything from genuine reuse credit to a fresh development with sentimental attachments.
- Decide tool qualification per tool, early. Each qualified tool is an investment case: qualification cost against the manual labour it retires, multiplied by how many programmes will reuse it.
- Price the second programme when buying the first. Much of a first programme's cost is building capability — plans, standards, environments, trained people — that the next programme inherits free. A first-programme quote read as a per-programme cost overstates every programme after it.
- Budget closure, not just reviews. The SOI meeting costs days; the findings cost weeks.
What this means for a Canadian supplier entering the field
For a firm building DO-178C capability for the first time — increasingly common as Canadian programmes source domestically — the framing matters more than the estimate: the first programme is partly a capability investment, and pricing it as pure project cost makes it look worse than it is. The disciplines above, plus the delegation and validation questions covered elsewhere in this series, are exactly where early advice pays for itself — not because the standard is mysterious, but because the expensive mistakes all happen before most teams think the certification work has started.
Frequently asked questions
So what does DO-178C actually cost?
Anyone who answers without asking your level, your requirements maturity, your reuse position, your tooling and your team's history is quoting folklore. With those five answered, a defensible estimate is possible — and the honest range between good and bad answers to those questions spans several times the base cost.
Is Level A twice as expensive as Level C?
There is no stable multiplier. The C-to-A step adds relatively few objectives but sharply increases independence and adds MC/DC and source-to-object traceability — the cost lands in staffing and verification infrastructure. For most programmes the D-to-C step is the bigger budget shock, because that is where structural coverage and most of the objective count arrive.
Does DO-178C double the schedule?
On a well-planned programme, assurance adds materially less than teams fear — much of the work is engineering they should be doing anyway, done in an auditable form. On a badly-planned one, doubling is optimistic. The variable is not the standard; it is when the assurance work starts relative to the code.
Can we reduce cost by qualifying tools?
Sometimes substantially — a qualified coverage or analysis tool retires recurring manual effort. But qualification has real cost, so it is an investment decision per tool, strongest when amortised across programmes. A single small programme rarely justifies qualifying a tool from scratch.
Is it cheaper to certify existing software than to rewrite?
Not reliably. Retrofitting evidence onto code that was not built for it — reconstructing requirements, reverse-engineering design rationale, chasing coverage on an untestable architecture — regularly costs more than a disciplined redevelopment. It depends on what evidence already exists, which is precisely what a gap analysis establishes.
Scoping a first programme, or sanity-checking an estimate you have been given? That is a conversation worth having before the budget is committed — get in touch.
