Three other systems' data2026

Post-booking operations platform

An operations platform that reads across three systems it doesn't own, without copying any of their data.

Role
Sole engineer on the product layer
Stack
Next.js · React · TypeScript · Tailwind · Radix UI · dnd-kit · Recharts · Zod · Firebase Cloud Functions · Firestore

Client work. System names, screenshots and business figures are omitted.

What it took
  • A live operational need with a team waiting on it
  • Three existing systems, none of them mine, all of them still changing
  • A shared database with a ruleset I didn't control
The problem

Everything that happens after a sale is its own job: rooming, briefings, documents, tour leaders. It needed somewhere to live.

But almost everything it depended on already existed somewhere else, spread across three other internal systems. The obvious move is to copy what you need into your own database. The obvious move is also how you end up with two versions of the truth.

What I did

Two layers with a hard boundary between them. A read-only federation layer sits over the collections the platform doesn't own and never writes to them. A separate store holds what operations genuinely owns: rooming lists, review baselines, tour leaders, briefings, and an append-only audit log.

Identity is inherited from the group single sign-on, exchanged server-to-server for a token scoped to this application alone. Authorisation is the platform's own, with role templates and a per-feature permission matrix.

Decisions

The parts worth arguing about.

01

Read, don't copy

Nothing owned by another system is duplicated. There is no sync job, no reconciliation, and no possibility of drift, because there is only ever one copy of anything. The cost is that the platform is only as available as the systems it reads from, which was the right trade here.

02

Append-only for anything that matters

The audit log is written to and never edited. If you want to know what happened and when, the record is the record.

03

Inherit identity, own authorisation

Reusing the group sign-on meant no new credentials for anyone. Keeping authorisation local meant this platform's permissions could evolve without touching a system four other applications depend on.

What came out

Live, with the team trained and using it daily.

It gives the post-booking team a single working view over records held across three other internal systems, without duplicating any of it.

What isn't there

No tests. Not thin coverage, none: no test files, no runner, no CI. It was built quickly against a live operational need, and the tests haven't been written yet. That is a normal trade to have made and an abnormal one to leave standing, so it's the first thing I'd add.