Do You Actually Need DO-178C Compliance If You’re Not Building a Certified Aircraft?
Here is the question arriving in engineering leadership inboxes across the UAM, advanced air mobility, and avionics-adjacent sectors right now: our vehicle isn’t certified yet, we don’t have a type certificate application in, and our software team is moving fast on flight control algorithms and ground control station interfaces. Do we actually have to follow DO-178C? Can we build now and certify later?
The short answer is: you are not legally required to follow DO-178C today if your aircraft doesn’t have an active certification basis that invokes it. But the practical answer is more complicated, and for most teams reading this, the practical answer is the one that matters.
What DO-178C Actually Requires — and What Triggers It
DO-178C, formally titled Software Considerations in Airborne Systems and Equipment Certification, is a guidance document published by RTCA. It is not a regulation. FAA Advisory Circular 20-115D (and equivalent EASA guidance) makes DO-178C an accepted means of compliance with airworthiness regulations — specifically 14 CFR Part 25 (transport category), Part 23, Part 27, Part 29, and the emerging Part 23 MOSAIC rules, among others.
This means DO-178C is triggered when a certification authority accepts it as the compliance path for your software in the context of a specific type design. If you are not pursuing a type certificate, supplemental type certificate, or amended type certificate that invokes airborne software requirements, DO-178C is not technically required.
The standard defines five Design Assurance Levels — DAL A through DAL E — based on the severity of failure conditions your software’s malfunction or loss would cause to the aircraft. A DAL A failure condition is catastrophic. A DAL E failure has no safety effect. The level drives the rigor of your planning, requirements, design, coding standards, testing, and verification — with DAL A requiring independent review at nearly every step and generating a substantial artifact set that becomes part of the certification data package.
This matters because “compliance with DO-178C” means very different things at DAL C versus DAL A. Teams that say they are “DO-178C compliant” without specifying DAL are not saying much.
Where the Boundaries Actually Are
Several common development scenarios sit near the edge of DO-178C applicability. Let’s be precise about each.
Uncertified vehicles in development. If you are building an eVTOL that has no active G-1 issue paper with the FAA or no declared certification basis with EASA, DO-178C is not required. You are building under general engineering discipline. The question is whether you are building in a way that will survive the certification campaign you intend to start in 18 or 36 months.
Ground support equipment (GSE). Software that commands charging systems, performs maintenance data download, or runs pre-flight checks on the ground is generally not airborne software in the regulatory sense. FAA Order 8110.49 and the DO-178C scope definition both focus on software whose failure could affect the airborne system’s ability to perform its intended function. GSE software can affect airworthiness indirectly — particularly if it modifies loadable software or configuration data — but its primary regulatory treatment differs from airborne software. ARP4754A and the system safety process will often determine whether GSE software needs any formal software quality assurance process, and at what level.
Simulation and modeling tools. Software used to develop or verify airborne software is treated under DO-330 (Tool Qualification) if that software eliminates, reduces, or automates a verification activity that DO-178C would otherwise require manually. A simulation environment used to validate flight control laws may need Tool Qualification if its outputs are used as a substitute for testing on target hardware. A simulation used only to explore design options has no qualification burden.
Flight control algorithms running on research or experimental aircraft. An experimental category aircraft (FAA Form 8130-12, E-LSA, or Part 91 operations under experimental certificate) has no DO-178C burden unless the operator or a certification program explicitly invokes one. Some experimental operators choose to follow DO-178C-compatible practices anyway, either for safety or to preserve optionality for future production programs.
What “Partial Compliance” Looks Like in Practice
DO-178C does not define a “partial compliance” tier. You either have a compliant software development process for the stated DAL or you do not. Certification authorities assess compliance holistically — they review plans, artifacts, and process evidence together.
What teams often mean when they say “partial compliance” is one of two things:
-
Selected process elements adopted. A team applies requirements traceability, uses a formal coding standard, and runs structured test campaigns — but does not generate the full artifact set (Software Development Plan, Software Verification Plan, Software Configuration Management Plan, and so on) or perform independent verification. This produces better software than undisciplined development. It does not produce a compliance argument.
-
Compliance at a lower DAL than will eventually be required. A team applies DAL C discipline to software that will ultimately be classified at DAL B or A. This is better than nothing, but the gap between DAL C and DAL A is not cosmetic — it involves independence requirements, modified condition/decision coverage (MC/DC), and structural coverage analysis that cannot easily be back-applied to code written without those constraints.
Neither of these is the same as building a compliance-ready process from day one. The difference becomes visible when the certification campaign opens.
The Real Cost of Ignoring DO-178C Discipline Until Forced
The question engineers should be asking is not “is it required today” but “what does it cost to retrofit versus to build right.”
The certification data package for airborne software at DAL B or A is substantial. It must demonstrate that every high-level requirement traces to system requirements. Every low-level requirement traces to high-level requirements. Source code traces to low-level requirements. Test cases trace to requirements. Test results trace to test cases. Structural coverage data confirms that test execution exercised the code at the required coverage level.
If your requirements were written in a shared document, evolved through comment threads, and your test cases were captured in a spreadsheet, rebuilding that traceability under certification schedule pressure is not a documentation project. It is often a re-engineering project, because you discover that requirements were implicit in the code, that test cases don’t map to discrete requirements, and that the architecture assumed during design doesn’t match what was built.
Experienced DO-178C program managers routinely estimate that requirements reconstruction and traceability rebuild on unprepared codebases adds 12 to 24 months to a certification schedule and introduces substantial re-test scope. For a UAM company with investor milestones tied to certification dates, that is not a documentation overhead. That is a company-threatening schedule risk.
How Modern Tools Change the Calculus
The traditional argument for deferring DO-178C discipline was partly about tooling cost and overhead. Legacy requirements management tools — IBM DOORS, Polarion, Codebeamer — carry significant implementation cost, require dedicated administrators, and are genuinely hard to use for engineering teams without formal DOORS training. Jama Connect improves on usability but still operates primarily in a document-centric paradigm that makes graph-structured traceability difficult to maintain as systems evolve.
The tooling picture has changed. Platforms built specifically for systems and hardware engineering teams can structure requirements, traceability, and verification closure in ways that are DO-178C compatible without requiring a team to hire a compliance specialist before they write their first requirement.
Flow Engineering is one platform that takes this approach directly. It structures requirements in a model-based, graph-connected way from the start — system requirements link to subsystem requirements link to software requirements link to verification activities, with traceability maintained as living relationships rather than as a spreadsheet someone updates manually. For a UAM startup in pre-certification development, this means the traceability architecture exists when the certification campaign opens, not as something to be reconstructed.
The practical implication is that a team using Flow Engineering to manage requirements during development is not “doing DO-178C” — they are not generating Software Development Plans or conducting formal independent reviews. But their requirements structure, coverage, and traceability are already shaped in the way a DO-178C compliance argument needs them to be. The delta between their current state and a certification-ready data package is substantially smaller.
Flow Engineering does not replace the certification expertise, the DER relationships, or the verification rigor that DO-178C requires. What it eliminates is the reconstruction phase — the 12-month archaeology project where engineers try to prove that requirements they wrote two years ago actually governed the code they built. That is not a small thing.
A Practical Decision Framework
If you have no certification program and no plan to certify: Apply sound engineering discipline. You are not required to follow DO-178C, and treating it as required will create overhead without regulatory benefit. But structure your requirements so they can be traced. Document assumptions. Don’t let your verification strategy live only in someone’s head.
If you plan to certify within three to five years: Build your requirements and traceability architecture as if DO-178C will apply, because it will. The investment is small. The avoidance cost is enormous. Pick tooling that supports structured requirements and connected traceability natively, not as an afterthought.
If you build ground support or simulation software: Understand whether your software touches loadable data or eliminates a verification activity. If it does, engage a DER early to determine qualification scope. Don’t assume “not airborne” means “no process required.”
If you’re working on experimental aircraft: You have a genuine option. Many teams in this space use DO-178C-compatible practices because it produces better safety outcomes and preserves the path to production programs. Others operate under explicit risk acceptance. Know which situation you are in and document your choice.
Honest Assessment
DO-178C is a demanding standard built for software whose failure modes can kill people. Its rigor is not bureaucratic excess — it reflects hard-won knowledge about what it takes to build software that behaves predictably in an environment where retesting is not possible.
The question “do I need it” is almost never the right question for teams building toward certification. The right question is “how do I build now so that the certification campaign is an assessment, not a reconstruction?” Requirements management and traceability are where that question gets answered — and where poor early decisions create the worst downstream debt.
The teams that will make their certification schedules are the ones treating their requirements architecture as a first-class engineering artifact from day one, not as compliance documentation to generate after the fact.