No-code customization layer for AMOS and AirData

The moment this becomes painful is when an MRO's operations manager wants to add a custom field to a work order — maybe a customer PO reference, maybe a specific airframe identifier — and the answer from IT is 'that requires a consultant and a change request.' Users explicitly complain that 'customization is hard, requires technical expertise.' That's not a one-time problem; it happens every time a regulatory requirement changes, every time a new airline customer has different reporting needs, every time internal processes evolve.

The reason this gap exists structurally is that MRO software vendors make money on implementation services and customization consulting. Every hour a customer spends with a third-party consultant getting their system configured the way they need it is either revenue to the vendor's professional services arm or revenue to a certified partner. Vendors have a direct financial incentive not to make this self-service. The buyer — usually an IT or ops director — knows this but accepts it as the cost of enterprise software. The user — the planner who can't add a field — has no purchasing power to fix it.

What's missing is a configuration interface that lets non-technical operations staff make the kinds of changes that currently require a ticket: custom fields, custom views, conditional logic on forms, and role-based field visibility. Not full programming — just the 20% of customizations that cover 80% of real requests, without touching the underlying database schema.

This recurs constantly because regulatory changes (EASA, FAA) force form and process updates regularly, and no MRO operation stays static. The alternative today is a backlog of IT requests, consultants billed by the hour, and months of waiting — which is exactly what complaints describe as 'significant time and training' and 'limited flexibility.'

What to build

Build a configuration middleware that connects to AMOS or AirData via their existing API or database export layer and lets operations administrators define custom fields, form layouts, and conditional display rules through a visual interface — with changes reflected in the live system without a code deployment.

Where to start

Target AMOS customers specifically during the post-implementation period — typically six to eighteen months after go-live — when the initial consultant has left and the backlog of 'minor improvements' mentioned in complaints starts to pile up with no clear owner.

The hard part

MRO vendors can legally restrict API access or change their data models in ways that break your middleware, and because you're touching live maintenance records, a single data integrity bug creates liability exposure that could kill the product before it scales.

How it makes money

Annual subscription per MRO operation (not per seat, since this is used by a small admin team), priced as a fraction of what a single customization engagement with a certified AMOS consultant costs.