Build vs Buy: Why In-House Compliance Systems Break

Estimated read time: 5 minutes

Somewhere, in most aviation organizations, sits a compliance system built by someone in-house. It often starts as a spreadsheet tracking crew or technician qualifications, then grows to include training data, audit findings, and manual revisions. It works, and one person understands it completely.

Building in-house feels like the sensible choice. You have an IT team and domain experts, and there is no procurement process to fight against. The trouble is that this decision usually fails late, not at launch, but potentially years later, when regulations have shifted several times, and the person who built it has left.

Organizations default to building

Ask most aviation organizations whether to build or buy their compliance tools, and the instinct is to build, or at least to keep patching what has already been built. The cost of that habit is starting to show. A 2026 MRO survey of more than 150 airlines, MRO, and OEM professionals found the industry's push into AI is stalling on data quality, with a significant amount of operational data still sitting in legacy systems and paper records. Yet while half of respondents plan to invest in AI over the next five years, only a third plan to invest in the IT infrastructure underneath it.

The reason is rarely technical. Business research points to entrenched habits and internal bias: the in-house option already has an owner and a team, so it tends to win the argument before the alternatives are properly weighed. In aviation, that habit carries a particular cost, because compliance software is never finished.

Your compliance software does not belong to you

An ordinary internal tool changes when your business changes. Compliance software changes when the regulator does. Take Part 145 organizations: in roughly two years they have absorbed the end of the SMS transition and the arrival of Part-IS, which since 22 February 2026 has required an operational information security management system under 145.A.200A. Add new postholder structures and a fresh amendment to the Part-145 guidance material in July 2026. The same steady churn runs across flight operations, crew training and safety management.

Every one of those changes lands on an in-house system as new work. A commercial platform builds each update once and delivers it to every customer. An internal team has to interpret, build, test and document it alone, usually alongside their day job. If you hold both UK CAA and EASA approvals, the load is heavier still, because since Brexit you are maintaining two approvals against two rulebooks, and your system has to keep pace with both.

The build estimate is not the cost

When an in-house build gets signed off, the number on the table is usually the cost of getting the first version live. That is the cheap part. Industry research puts maintenance at 60% to 80% of a system's total lifetime cost. Especially in compliance software, most of that maintenance is driven by the regulatory changes mentioned above. So the bill keeps arriving long after the project closes, and it grows every time the one engineer who understands the code is missing or leaves.

Does AI change the maths?

AI coding tools make a first version faster to build, and some organizations now use AI to monitor regulatory change. Both help immensely, but neither actually removes the work.

AI can flag that a regulation has changed, but someone still has to decide what it means for your operation, change the system, test it, document it, and stand behind it at audit. Faster code also means more code to own (and test): every feature built in an afternoon is a feature someone secures, maintains, and explains to an inspector for years afterwards.

In other words, AI lowers the cost of the first release, which was already the cheap part. The long tail of ownership still sits with you. So the real question is not whether your team can build it with AI. It is whether the hours they spend maintaining software would be better spent maintaining aircraft.

Regulators audit the proof, not the tool

When the auditor arrives, it does not matter who built your system. What matters is whether it can prove what happened: which revision of a work instruction was current on a given date, who approved it, and which technicians acknowledged it. A commercial platform is built to produce that evidence, because every customer needs it. In an in-house system, audit trails are often the first feature cut when a project runs late, and nobody notices the gap until it matters.

Try this test. Ask whoever owns your internal system to produce, today, the full change history of one work instruction. If the answer depends on one specific person, you do not have a system. You have a singularity in the form of a person.

How it usually plays out

Back to that spreadsheet we talked about earlier. A repair station builds its own tracker for technician authorizations, and it does the job. The SMS transition adds hazard logging, so a new tab appears. Then Part-IS asks for an asset register, and access controls the tracker was never designed to provide. By now the person who built it has moved away from your organization, and every change means someone relearning the logic first. Nothing has failed. The system has simply become the most expensive spreadsheet in the building, and the hardest one to audit.

Nobody is competing to improve your in-house system

A software vendor has to keep earning your renewal. Competitors pitch for your business every year, so the product has to keep getting better: new features, faster workflows, regulatory updates ready before the deadline rather than after it. And every customer benefits from improvements requested by an ecosystem of customers requesting new features.

An in-house system has no competitor. Nobody loses a contract if it stands still. Few aviation organizations employ a product team whose whole job is working out what the system should do next year, and they shouldn't need to. So in-house tools tend to do exactly what they did on launch day, while the regulation and the operation move on around them.

When building makes sense

Build when the process genuinely differentiates you, the scope is narrow and stable, or you are connecting platforms rather than replacing them. What rarely passes the test is the regulated core: document control, qualification tracking, safety reporting, and audit evidence. They are mandatory for everyone and change on someone else's schedule. There is no advantage in doing them yourself, only the risk of doing them wrong.

The question to ask first

Before you sign off the next internal build, change the question from "can our team build this?" because with or without AI they probably can. Ask "do we want to own every regulatory change that lands on it for the next ten years, or would we rather spend that time on our aircraft?"

If the honest answer is no, that spreadsheet in the corner has already told you what to do.