Certification and Speed Are Not a Trade-Off

There is a belief, common enough that people rarely question it, that certification and speed pull in opposite directions: that to move fast you must cut process, and to satisfy a standard like DO-178C you must slow down. I have come to think this framing is not just wrong, it is the actual source of the delays people blame on certification. The problem is almost never the rigor. It is how teams choose to spend it.

The delay is not caused by certification

When a safety-critical programme stalls early, the cause is usually not the standard. It is a team writing plans and documents for a product that does not exist yet. Pages of process are produced before a single design decision has met reality. This feels like certification work, so it is easy to blame the standard for the lost weeks. But the standard never asked for documents about guesses. It asked for evidence about a real system. Producing the former instead of the latter is a choice, and it is the choice that costs the time.

You cannot bolt certification on later

It is tempting to conclude that the fix is to build first and certify later. In something like DO-178C, that does not work, and understanding why is the whole point. Certification is not a test you pass at the end. It is a trail of evidence, requirements, design, traceability, reviews, structural coverage, that has to exist from the beginning, because an examiner needs to follow it back through the life of the system. Evidence you did not capture as you went cannot be reconstructed honestly afterwards. So "certify later" is not a faster path. It is a rebuild.

Build the safety case with the product

The path that is actually fast is neither process-first nor process-last. It is to build the product and its evidence together. Prototype early to kill the technical unknowns, the timing, the sensor behaviour, the integration seams, exactly the things a document cannot tell you. But keep the discipline alive from the first commit: real requirements, honest traceability, coverage that grows with the code. The safety case is not a phase at the end. It is something you grow one increment at a time, alongside the product it describes.

Certification is not a gate you reach. It is a trail you leave.

Done right, rigor makes you faster

This is the part that surprises people who see rigor only as a tax. Good requirements shrink scope creep, because everyone knows what "done" means. Traceability makes change safe, because you can see what a change touches. Structural coverage and reviews catch defects early, when they are cheap, instead of late, when they are expensive and integrated. A team with living discipline spends less time in rework and firefighting than a team moving fast on assumptions. The rigor is not slowing them down. It is the reason they are not constantly going backwards.

Cut the theater, not the rigor

If a programme wants to move faster, the thing to cut is not the evidence. It is the theater: documents nobody reads, plans written before the design is understood, ceremony that produces paperwork instead of proof. That is the waste that hides behind the word "certification" and gives rigor a bad name. Real certification work, requirements you can test, traceability you can follow, coverage you can defend, is lean by nature, because every artifact earns its place by being evidence of something real.

So the choice was never between shipping and certifying. It is between certification as living evidence, grown next to a working product, and certification as paperwork, detached from one. The first is both fast and safe. The second is slow and, quietly, still not safe. If you build the safety case the same way you build the product, one honest increment at a time, you do not have to choose.