Three connected platforms for aircraft technical publications, for SES (formerly Intelsat)

At a glance

• Three connected platforms: a technical publications database, a service request portal for airlines, and the content portal that delivers documents
• Scale: around 6,500 commits across six repositories, all three under active development
• Built on: Laravel APIs behind Next.js front ends, running on AWS
• The hard parts: revision, configuration and modification state per document; airline entitlement enforced at the data layer; signed server-to-server integrations

The problem

SES (formerly Intelsat) provides inflight connectivity to airlines worldwide. Every installation generates a large, constantly revised library of technical publications — maintenance manual supplements, wiring diagram manuals, engineering orders — and that documentation is both sensitive and version-critical. An airline needs exactly the documents that apply to its own aircraft, at exactly the right revision, and nothing belonging to anyone else.

Aviation makes that harder than ordinary document management. Publications hang off Supplemental Type Certificates, which vary by aircraft configuration; a document has a revision, a configuration, a modification list and its own revision state. Get the wrong version to an engineer and the consequence is not a bad user experience.

Alongside the documents sits a second problem: when an airline needs something — a new document, a change, a query against an existing publication — that request has to be raised, routed, tracked and answered against the right publication. Handled over email, it is invisible the moment it leaves the inbox.

Our approach

We build and run three connected platforms rather than one monolith, each doing a job the others should not.

The technical publications database is the source of truth. Documents, revisions, configurations and their relationships to certificates and aircraft live here, with role-based access, versioned records, and a full audit trail over who changed what. Airline entitlement is enforced at the data layer rather than in the interface, so a query can only ever return documents that airline is entitled to see.

The service request portal is where airlines raise and track requests. Each one carries status history, internal and public comments, attachments and categorisation, so a request has a visible state and an owner instead of living in somebody’s inbox. Automated notifications keep both sides informed as it moves.

The content portal is the delivery surface — the platform that gets the right publication to the right airline, watermarked and version-correct.

Connecting them

The three are only as useful as the joins between them, and those joins are where most of the engineering judgement went.

Documents flow one way from the publications database into the content portal for delivery. In the other direction, the service request portal reads from the publications database in real time, so an engineer raising a request picks the certificate and document number from live data instead of typing them from memory — the single largest source of error in the old process. That lookup is strictly read-only: a request can never write back into the publication record.

Both integrations are signed and verified server to server, with separate credentials per consumer so revoking one cannot break the other. Airline scoping is applied on both sides of every call rather than trusted from the caller, and the lookups are cached per airline so one airline’s results can never be served to another.

Because aviation data is never uniformly complete, the lookup enriches rather than gatekeeps. Where a certificate or document is missing from the database, the form falls back to manual entry instead of blocking the request — the integration makes the common path fast without making the uncommon path impossible.

The build

Laravel APIs behind Next.js front ends, running on AWS. Around six and a half thousand commits across the six repositories to date, and all three platforms are under active development and support — this is a long-running engagement rather than a project that shipped and stopped.

The outcome

SES runs its aviation technical publishing on platforms it owns: one place where the documentation is authoritative, one place where airlines ask for what they need, and one place where the right version is delivered to the right operator. The three talk to each other, so an engineer no longer retypes what a system already knows.

Related services: Technical Publications, Website Development, AWS Partner