A developer working on airborne software at the highest assurance level writes between three and twelve lines of code a day. At typical US aerospace engineering rates, that comes to around $100 per line. Certifying a hundred thousand lines is a multi-million dollar exercise before you count the cost of writing it.
People outside the industry assume this is because aircraft software is written more carefully. It is written more carefully, and that still does not explain the cost.
The figures here come from DO-178C, where the cost research is public. The structure they describe is not specific to aircraft. ECSS in European space systems, DO-278A in ground systems supporting air traffic, DO-254 in airborne hardware and NPR 7150.2 at NASA all work the same way. You demonstrate objectives, the demonstration takes evidence, and the evidence is where the hours go.
What You Are Actually Paying For
A certification program delivers two things: a software product and an evidence package, and the evidence package is the larger of the two.
DO-178C is built around objectives. Each objective is a statement you must demonstrate, and demonstrating it takes documents, reviews, tests, and records linking all of them together. The software satisfies your requirements. The evidence satisfies the regulator, and only the regulator decides whether anything ships.
This is where the comparison to commercial software falls apart. A team building a consumer app also writes requirements and runs tests, so the process looks similar from a distance. The difference is what those documents are for. In commercial work they serve the team, and the team decides how thorough to make them. Under DO-178C they are the deliverable, they have defined content, and someone who did not write them will examine them.
That difference tells you what is worth fixing. Most attempts to cut certification cost go after the code, through better languages, better tooling, faster development practice. Those efforts address the smaller half of the problem. The hours are in the evidence, and evidence work has stayed manual because it is too important to hand to a tool that cannot show its reasoning.
AeroCert was built for that work. It produces certification documents through a symbolic engine called Socrates, which composes each document by reasoning over an explicit structure rather than predicting text. The derivation can be inspected. The same input produces the same output. The links between documents come from the reasoning that created them. Squint reports effort reductions above 90 percent on this document work.
Whether that helps your program depends on three things that drive its cost.
The Cost Depends on Consequence
Two functions can be identical in length, logic, and difficulty, and one can cost several times more to certify than the other. The difference is what happens if the function fails.
DO-178C assigns each piece of software a design assurance level based on the severity of its failure condition, from catastrophic down to no safety effect. As the level rises, so does the number of objectives you must satisfy and the requirement for independence between the person doing the work and the person verifying it. One estimate puts the cost of developing a flight guidance system at the highest level at roughly three times the cost of the same system a level or two down.
The engineering did not change. The consequence of failure changed, and your evidence obligation changed with it.
Automated document production helps most here, because the expensive levels are the ones demanding the most evidence. A tool that shortens document work saves you little at Level D and a great deal at Level A.
Even the lowest certified level carries real structure. Level D still requires full planning, high-level and low-level requirements, implementation, reviews, and functional testing of every high-level requirement with traceability applied. No configuration of DO-178C lets you ship quickly and fix forward.
Everything Loaded Into Memory
Teams new to certification are often surprised by scope.
In DO-178C, software means every executable element loaded into memory. Your drivers, board support package, real-time operating system, libraries, graphics stack, and application code all sit inside the boundary. If you budget for your own application and plan to pull in an operating system and a graphics library, you have budgeted for a fraction of what needs certifying.
This is why commercial components are sold with certification evidence packages rather than as ordinary software. The evidence has to exist for everything in the build. Producing it after the fact, for a component nobody wrote with certification in mind, is one of the most expensive things a program can discover late.
AeroCert can work in that direction. Given existing source code, it identifies which documents the standard requires, which of them the code already supports, and what you have to produce from scratch. That turns an open-ended cost into an estimate you can see before you commit.
Changes Cost More After Delivery
Commercial software gets cheaper to change after launch, because the team learns the codebase and builds tooling around it. Certified software works the other way around, and the reason is the evidence rather than the code.
Any change triggers recertification effort, and you have to establish what else the change affected. Requirements may need updating. Tests may need rerunning. Trace links may need revising, and all of it needs reviewing again. Teams that cannot tell precisely what a change touched re-verify broadly, because verifying too much is safer than verifying too little.
Across a product life measured in decades, that recurring cost often exceeds the original certification.
Deterministic document production helps twice here. Documents that regenerate identically stay consistent with each other over years. More usefully, because AeroCert stores the intent of each function as an encoded structure, it can compare a modified function against the original and tell you whether the purpose changed or the edit was cosmetic. A refactor updates the affected requirement, while a change of purpose updates all of them for that function. That turns broad precautionary re-verification into a narrower, justified one.
Where the Money Goes
The premium on certified software is the cost of proving something to a standard where the alternative to proof is not shipping. It is not caution and it is not inefficiency.
That tells you what to do about it. Writing the code faster barely moves your total. Producing the evidence differently changes the arithmetic, because the evidence is where the money was in the first place.
