Industry
Software engineering for Aviation
Aviation is safety-critical and heavily regulated, and it runs on some of the most entrenched legacy systems in any industry. The hard part is rarely the interface: it is the regulatory weight of the CAA and EASA, integrating with airline systems that predate the web, and building for a reliability standard where a failure is a grounded aircraft or a safety event, not a bad user session. We build for that reality, with the seriousness it demands.
Why the domain matters
Aviation is a sector where software carries consequences that most industries never have to reckon with. An error in a booking engine is an annoyance; an error in an airworthiness record, a weight-and-balance calculation, a crew-duty limit or a slot allocation can be a safety event or a grounded aircraft. The industry is heavily regulated for exactly that reason, sitting under the Civil Aviation Authority in the UK and the European Union Aviation Safety Agency across Europe, with international frameworks from ICAO and IATA layered on top. It is also one of the most operationally complex industries there is: airlines, airports, maintenance organisations and ground handlers each run intricate operations that have to interlock precisely, in real time, across the world, every day, in all weather. Software that serves this sector has to earn its place in that environment, and the bar is high.
The market divides into distinct operations, and software lands differently in each. Airlines live on reservations and departure control: the systems that sell seats, manage inventory, check passengers in and control the departing flight. Most of it still routed through the global distribution systems and passenger-service systems that have run the industry for decades. Airports run ground operations, resource allocation, and the choreography of aircraft, stands, gates and passengers. Maintenance, repair and overhaul organisations keep aircraft airworthy, and their world is dominated by records: every component, every task, every inspection, tracked and evidenced to a standard the regulator can audit. Ground handling turns an aircraft around against the clock. And slot management governs who may use congested airports and airspace when. Each of these is a specialism, and each carries its own regulatory and reliability weight.
We are a senior-led team and we operate what we build, and we are candid that aviation is not a sector to approach lightly or to learn on. The genuinely hard parts here are threefold: the regulatory weight, where the CAA and EASA reach into what software must do and evidence; the legacy systems, where airline reservations, distribution and airport infrastructure run on deeply entrenched platforms that predate the web and are not going anywhere; and the reliability standard, where safety-critical and operationally critical systems cannot simply fail over and retry the way a consumer app can. We build with that seriousness, we are honest about the boundaries of what software should decide versus what a certified human or system must, and we would rather tell you plainly where a component sits on the safety-critical spectrum than let anyone assume a comfortable answer.
The challenges in aviation
Regulatory weight that reaches into the software
Aviation sits under the CAA and EASA, with ICAO and IATA frameworks on top, and these are not light-touch regimes. Airworthiness, crew flight-time limitations, records retention, and operational approvals all carry rules that shape what software must capture, calculate, evidence and retain. Where a system touches a regulated function, getting it wrong is not a bug ticket: it is a compliance exposure or a safety concern for an operator whose licence depends on it. The regulation is a first-order design input here, not a compliance annex bolted on at the end.
Entrenched legacy airline systems
The industry runs on some of the oldest continuously operating systems in commercial computing. Reservations, distribution and passenger-service platforms (the GDS and PSS estate), and much airport infrastructure predate the web and are deeply woven into how the business works globally. New software almost always has to integrate with, sit alongside, or carefully feed these systems rather than replace them, and any plan that assumes a clean greenfield ignores the platforms the entire operation depends on every second of every day.
A reliability standard where failure grounds aircraft
Operationally and safety-critical aviation systems cannot fail over and retry the way a consumer app can. A departure-control outage stops boarding; a maintenance-records failure can ground a fleet; a safety-critical calculation cannot simply return a plausible-looking wrong answer. The reliability, resilience and correctness bar is far higher than in most commercial software, and designing for it (redundancy, graceful degradation, provable correctness where it matters), is core work, not a non-functional afterthought.
Airworthiness and records that must be audit-perfect
MRO lives on records: the complete, traceable history of every aircraft and component, tasks performed, parts fitted, inspections signed, life-limited parts tracked against their limits. The regulator can audit this, and an aircraft is only legal to fly if its records prove it airworthy. Software here has to maintain that evidence with absolute integrity and traceability, because a gap, an unrecorded task or a mis-tracked life-limited part is not a data-quality issue. It is a grounded aircraft or a serious safety risk.
Crew, duty limits and the cost of getting rostering wrong
Crew rostering has to respect flight-time limitations and rest requirements that exist for safety reasons, alongside qualifications, currency, licensing, industrial agreements and the sheer combinatorial complexity of assigning crews to a rolling schedule. A roster that breaches duty limits is both illegal and unsafe; one that is merely inefficient costs real money and resilience. This is hard optimisation under hard constraints, where the safety constraints are non-negotiable and the software must enforce them, not merely suggest them.
Real-time operations that interlock precisely
Airports, airlines, handlers and air-traffic constraints have to synchronise in real time: an aircraft turnaround touches stands, gates, fuel, catering, baggage, crew and slots, and a delay propagates through all of it and across the network. Software supporting ground and airport operations has to cope with constant disruption (weather, delays, diversions, cancellations), and help recover, rather than assuming an on-time world. Building for the disrupted day, not the schedule as printed, is where operational aviation software is genuinely tested.
What we build for aviation
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Reservations, inventory and departure control
Systems and integrations across the passenger journey, reservations and inventory, check-in and departure control, and the surrounding retailing and servicing, built with clear-eyed respect for the GDS and PSS estate they have to work with. We treat distribution and passenger-service integration as the entrenched, first-class problem it is, and design so the software adds genuine capability around those platforms rather than pretending it can casually replace infrastructure the whole industry depends on.
MRO and airworthiness records
Maintenance, repair and overhaul systems where records integrity is the whole point: complete task and inspection history, component and part tracking, life-limited part management against hard limits, and airworthiness evidence a regulator can audit. We build these with the traceability and integrity the regime demands, because in MRO the record is what makes an aircraft legal to fly, and a system that loses, gaps or mis-tracks that evidence is a safety and compliance failure, not merely a defect.
Crew management and rostering
Crew systems that manage rostering, qualifications, currency, licensing and the flight-time limitations and rest rules that exist for safety, alongside the industrial and efficiency constraints operators care about. We build so the safety constraints are enforced by the software rather than left to the planner to remember, and treat the optimisation seriously, because a roster that breaches duty limits is unsafe and unlawful, while one that is merely inefficient quietly costs money and resilience every single day.
Airport and ground operations
Systems for the real-time choreography of the airport and the turnaround, resource and stand allocation, ground-handling coordination, and the operational picture that keeps aircraft, gates and passengers moving. We build these for the disrupted day rather than the printed schedule, so they help the operation absorb and recover from weather, delay and diversion, because the value of operational software here is measured on the bad day, not the one where everything ran on time.
Slot management and capacity
Software supporting slot management and capacity at congested airports and in constrained airspace, where who may operate when is governed by rules and scarce allocations. We build these with respect for the coordination frameworks and the seriousness of the allocations involved, because a slot is a valuable, regulated right and the systems that request, track and honour them have to be accurate and auditable rather than approximate.
Integration and operational data across the estate
The integration layer that lets airlines, airports, handlers and maintenance organisations share operational data reliably, messaging and interchange across the standards and legacy interfaces the industry runs on. Much of the real engineering in aviation is here, in making entrenched, heterogeneous systems agree about the state of a flight, an aircraft or a passenger in real time, so we treat this interchange as core work rather than plumbing bolted on beneath a nicer front end.
Where we help
Adding capability around a legacy PSS without replacing it
An airline wants new servicing, retailing or operational capability but cannot rip out the passenger-service and distribution platform the whole business runs on. The real work is integrating cleanly with the GDS and PSS estate (its messaging, its data model, its constraints), and building the new capability around it so it adds value without destabilising infrastructure the operation depends on every second. Done with respect for the legacy, it works; done as a naive replacement, it breaks a running airline, which is not an option.
Tightening airworthiness records for an audit-ready MRO
A maintenance organisation needs its records to prove airworthiness to the regulator without gaps: every task, inspection and part traceable, every life-limited component tracked against its limit. We build the records system so the evidence is complete, tamper-evident and auditable, and so a life-limited part cannot quietly run past its limit unnoticed. The outcome is aircraft that are demonstrably legal to fly and an organisation that can face an audit calmly, because in MRO the record is the airworthiness, not a description of it.
Rostering crews within flight-time limits automatically
An operator rostering crews across a rolling schedule needs the flight-time limitations, rest rules, qualifications and currency enforced, not merely advised. We build the rostering engine so it treats the safety constraints as hard and non-negotiable while optimising within them for efficiency and resilience. The measurable win is legal, safe rosters produced faster and with fewer manual breaches to catch, because a duty-limit breach that reaches an actual flight is both a safety failure and a regulatory one, and the software’s job is to make that impossible, not unlikely.
Keeping a turnaround on track through disruption
An airport or handler coordinating turnarounds needs stands, gates, fuel, catering, baggage and crew to synchronise against the clock, and needs to recover when weather or a delay upsets the plan. We build the operational systems for the disrupted day: surfacing the knock-on effects, helping re-allocate resources, keeping every party working from the same real-time picture. The value shows on the bad day, when a well-built system helps the operation absorb and recover from disruption instead of amplifying it across the network.
How we build for aviation
We start by placing each component honestly on the safety-critical spectrum, because that placement changes everything about how it must be built. A passenger-facing retailing feature and an airworthiness-records function or a duty-limit calculation are not the same kind of software, and pretending they are is dangerous. We are explicit from the outset about which parts touch regulated or safety-critical functions and which do not, and we engineer each to the standard its consequences demand rather than applying one comfortable level of rigour across the board.
We treat the legacy estate and the regulatory regime as the defining constraints, resourced accordingly. The GDS, PSS and airport infrastructure are entrenched and going nowhere, and the CAA and EASA reach into what software must do and evidence, so we plan for the awkward interfaces, the interchange standards and the compliance requirements from day one. Any plan that assumes a clean greenfield or treats regulation as an annex will discover both late, when the front end is finished and the system cannot actually be flown behind.
We build for the reliability standard the sector genuinely requires. Operationally and safety-critical systems cannot simply fail over and retry, so we design for redundancy, graceful degradation and correctness where correctness is non-negotiable, and we build for the disrupted day rather than the schedule as printed. This is core engineering in aviation, not a non-functional afterthought, because a failure here is a grounded aircraft, a stopped boarding gate or a safety event, not a bad user session.
Because we operate what we build, the people who design a records workflow or a rostering constraint are the ones accountable when it has to hold up. That concentrates the mind on the failure modes that actually matter in aviation: a gap in an airworthiness record, a duty-limit breach that slips through, an integration that desynchronises during disruption, and it keeps us honest about the boundaries of what software should decide versus what a certified human or system must. We would rather state those boundaries plainly than let anyone assume a comfortable answer.
Regulation and compliance
Aviation is regulated to a degree few industries match, and the regulation shapes the software rather than sitting beside it. In the UK the Civil Aviation Authority is the regulator, alongside the European Union Aviation Safety Agency across Europe, with the international frameworks of ICAO and IATA layered above. Airworthiness, continuing airworthiness management, crew flight-time limitations, operational approvals and records retention all carry rules that determine what software must capture, calculate, evidence and retain. Where our software touches any of these functions, we build to the requirement deliberately, because the compliance lives in the data and the calculation, not merely in the policy.
Airworthiness and maintenance records carry particularly heavy obligations. The regime around continuing airworthiness requires complete, traceable evidence that an aircraft and its components are maintained and legal to fly, auditable by the regulator, with life-limited parts tracked against hard limits. We design MRO records systems to hold that evidence with integrity and traceability, and to make gaps and out-of-limit conditions visible rather than silent, because in this domain the record is what makes the aircraft airworthy and a defect in it is a safety and legal exposure for the operator.
Crew flight-time limitations and rest requirements exist explicitly for safety, and rostering software has to enforce them. These are hard constraints, not preferences, so we build systems that treat a duty-limit breach as something the software must prevent rather than merely flag. The same seriousness applies to slot allocations and operational approvals, which are regulated rights and permissions with real weight, and which the software has to request, track and honour accurately and auditably rather than approximately.
We build systems that respect these obligations, but we are engineers, not your airworthiness, safety or aviation-regulatory advisers, and we do not hold the approvals the regulator issues. The obligations under the CAA and EASA carry serious legal and safety weight, and sign-off rests with your own accountable managers, safety and compliance functions and the certified people the regime designates. Our job is to build software that captures, calculates, evidences and retains what those obligations require, to be explicit about where a component sits on the safety-critical spectrum, and to work alongside the people accountable for airworthiness and safety.
Integration
The global distribution and passenger-service systems are the gravitational centre of anything airline-facing. Reservations, inventory, distribution and departure control run through the GDS and PSS estate, platforms that have run the industry for decades and that predate the web, and new software almost always has to integrate with them rather than replace them. We treat that integration as first-class engineering (respecting their messaging, data models and constraints), because these are the systems the entire commercial operation depends on, and pretending they are a simple API is how airline projects break something that was working.
Airport and operational integration runs on the industry’s interchange standards and a good deal of legacy infrastructure. Aircraft, stand, gate, baggage, fuel, catering, crew and slot data have to flow between airlines, airports and handlers in real time, across the messaging standards and interfaces the industry has built up over decades. Much of the genuine engineering in aviation lives here, in making entrenched, heterogeneous systems agree about the state of a flight, an aircraft or a turnaround, so we treat this interchange as core work rather than plumbing beneath a nicer front end.
Maintenance and airworthiness systems integrate with parts, component and manufacturer data, and with the operational systems that report aircraft utilisation and defects. Life-limited parts, task histories and inspection records depend on accurate data crossing these boundaries, so we engineer those flows carefully, because a records system that receives incomplete or inconsistent maintenance data cannot prove airworthiness however good its internal model is.
Crew, operations and the wider estate all have to interlock, and the recurring engineering problem across aviation is the same: keeping many entrenched, heterogeneous systems in agreement about the state of the operation in real time, under constant disruption. We treat that reconciliation as the core of the work, design for the interchange standards and legacy interfaces from the start, and build for the disrupted day when the systems most need to stay in step, rather than discovering the integration’s limits during the weather event that tests it.
Security and resilience
Aviation is critical national infrastructure, and its systems are a serious target as well as a serious safety responsibility, so security and resilience are not separable here. The most acute operational risk is availability: a departure-control or operational-systems outage stops boarding, strands aircraft and propagates delay across a network, so we engineer for redundancy, graceful degradation and recovery as core work, because in this sector an outage is grounded flights, not a bad user session, and availability is a safety-relevant property.
The data aviation holds is both sensitive and regulated. Passenger data, including passenger name records and the identity and sometimes special-category data that travel documents and assistance requirements involve: carries data-protection weight under UK GDPR and the sector’s own rules, and operational and airworthiness data is commercially and safety-critical. We build with access scoped to genuine need, encryption in transit and at rest, and deliberate handling of the most sensitive flows, rather than treating a global operational network as a trusted zone simply because it is behind an airline’s perimeter.
The integration surface is itself a risk. Aviation systems interconnect airlines, airports, handlers, distribution platforms and maintenance organisations across the world, and every one of those interfaces is a boundary that has to be secured and trusted appropriately. We are deliberate about authentication, segregation and the integrity of the interchange, because a compromised or spoofed operational message in this environment can have operational and safety consequences well beyond a typical data breach.
Because we operate what we build, resilience and security here are not a report handed over at go-live. We instrument for the failures that actually matter in aviation: an integration desynchronising during disruption, a records anomaly, an operational system degrading under load, keep the audit trail an investigation or a regulator would need, and rehearse the degraded and recovery modes rather than hoping they work. Treating the ability to keep operating safely, and to reconstruct exactly what happened, as part of the deliverable is the standard this sector demands.
What changes
Airworthiness evidence a regulator can audit calmly
Because we build MRO records with the integrity and traceability the regime demands, every task, inspection and life-limited part is complete, evidenced and out-of-limit conditions are visible, so aircraft are demonstrably legal to fly and an audit is a routine event rather than a scramble to reconstruct a history that should always have been complete.
Rosters that are legal and safe by construction
By enforcing flight-time limitations and rest rules as hard constraints in the rostering engine rather than advisory flags, crews are assigned within the safety limits automatically, so duty-limit breaches cannot reach a flight and planners spend their effort on efficiency and resilience instead of manually catching the breaches the software should have prevented.
Operations that hold together on the disrupted day
Because we build ground and airport systems for weather, delay and diversion rather than the printed schedule, the operation absorbs and recovers from disruption with every party working from the same real-time picture, which is where operational aviation software actually earns its value, not on the day everything already ran on time.
What we build for aviation
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for aviation?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in aviation choose us
We take the safety-critical spectrum seriously
We are explicit from the outset about which components touch regulated or safety-critical functions and engineer each to the standard its consequences demand, rather than applying one comfortable level of rigour across the board, because in aviation an airworthiness record and a retailing feature are not the same kind of software, and treating them as such is dangerous.
We respect the legacy estate instead of fighting it
The GDS, PSS and airport infrastructure are entrenched and going nowhere, so we integrate with them as first-class engineering rather than pretending we can casually replace platforms the whole industry depends on. That respect for the legacy is what separates software that adds real capability from a naive replacement that breaks a running operation.
We build for the reliability aviation actually demands
Operationally and safety-critical systems cannot simply fail over and retry, so we design for redundancy, correctness and the disrupted day as core work, not a non-functional afterthought, because a failure here is a grounded aircraft or a stopped gate, and that standard is not optional.
We operate what we build and state the boundaries plainly
The people who design a records workflow or a duty-limit constraint are accountable when it has to hold up, which keeps us focused on the failure modes that matter and honest about where software should decide versus where a certified human or system must. We would rather state those boundaries clearly than let anyone assume a comfortable answer.
Common questions
Can you build safety-critical aviation software?
We start by placing each component honestly on the safety-critical spectrum, because that placement determines how it must be built and who must approve it. Some aviation software (retailing, servicing, much operational tooling), is critical but not safety-critical in the certified sense; other functions, such as airworthiness records, weight-and-balance or duty-limit enforcement, carry direct safety weight. We engineer each to the standard its consequences demand and are explicit about which is which, and we are clear about the boundary: we are engineers, not your airworthiness or safety authority, so the certified approvals and safety sign-off rest with your accountable managers and the people the regime designates. We would rather state that plainly than let anyone assume a comfortable answer.
We run legacy GDS and PSS systems, can you work with them?
Almost always, and we plan for it from the start, because those platforms are the entrenched centre of the airline business and are not going anywhere. Reservations, distribution and departure control run through the GDS and PSS estate: systems that predate the web and are woven into how the operation works globally, so new software has to integrate with them, sit alongside them, or carefully feed them rather than replace them. We treat that integration as first-class engineering, respecting their messaging, data models and constraints, because pretending a legacy PSS is a simple modern API is how airline projects break something that was working every second of the day.
How do you handle airworthiness and maintenance records?
As a records-integrity problem where the record is what makes the aircraft legal to fly, so it has to be complete, traceable and auditable without gaps. We build MRO systems to capture every task, inspection and part fitted, to track life-limited components against their hard limits, and to make out-of-limit or missing-record conditions visible rather than silent, because a gap or a mis-tracked life-limited part is a grounded aircraft or a safety risk, not a data-quality niggle. The regime around continuing airworthiness lets the regulator audit this evidence, so we design for that audit from the outset. To be clear on the boundary: the airworthiness determination and sign-off rest with your certified staff, and we build the software that gives them evidence they can trust.
How do you handle crew rostering and flight-time limitations?
By treating the safety constraints as hard and non-negotiable, enforced by the software rather than left to a planner to remember. Flight-time limitations and rest requirements exist for safety, so we build the rostering engine to prevent a duty-limit breach reaching a flight, while optimising within those limits for qualifications, currency, industrial agreements, efficiency and resilience. A roster that breaches duty limits is both unsafe and unlawful, and one that is merely inefficient quietly costs money every day, so we take both seriously, but the safety limits are the ones the software must make impossible to breach, not merely unlikely.
Can your systems cope with disruption, weather, delays, diversions?
That is exactly what we design operational aviation software for, because its value shows on the bad day rather than the day everything runs on time. A turnaround touches stands, gates, fuel, catering, baggage, crew and slots, and a single delay propagates through all of it and across the network, so we build ground and airport systems for the disrupted day: surfacing knock-on effects, helping re-allocate resources, and keeping every party working from the same real-time picture. Building for the schedule as printed is easy and useless; building for the weather event, the diversion and the cancellation is where the engineering is real and where a well-built system helps the operation recover instead of amplifying the disruption.
Building for aviation?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if aviation is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.