Engineering notes and lessons from production systems.
· 4 min read
In most systems the expensive test outcome is red. In a booking system it is green — a passing test just bought something. How the full flow gets tested anyway: a selection rule that doubles as the safety mechanism, and an evidence pack, not a checkmark, as the thing partners actually review.
· 4 min read
Eight gateway services, one shared integration branch, and a promotion to production that is a deliberate, batched act with a human at the button. What "the unit of release is the set, not the repo" looks like when it has to run every week instead of sitting in a principles list.
· 9 min read
Not "AI writes my code". The useful part was turning ~70 procedures that lived in one person's head into commands anyone can run, with the dangerous ones labelled and gated. Here is the shape of it, in numbers I can actually count.
· 5 min read
"So you call other people's APIs" is the usual summary of my job, and it is wrong in an instructive way. Around 150 supplier codes on about 90 integrations, two documented offer patterns, two execution models behind one public contract, and suppliers that answer 200 with an error inside — a tour of what the work actually consists of, and why it is architecture.
· 5 min read
Not the integration mechanics — the domain underneath them. Inventory that changes between search and book, prices with a shelf life, cancellation policies that are data rather than a flag, five product lines whose shapes genuinely differ, and supply that is other companies. The hard part is what you are selling, not how you call it.
· 6 min read
The first day on a new supplier, I write no code. There is a fixed list of questions — auth and rotation, search shape, offer identity and lifetime, idempotency and what lookup exists without it, where errors live, whether policies are structured, what the rate model implies — and the answers decide the shape of the module. The estimate comes out of that reading, not out of the endpoint count.
· 5 min read
Every booking investigation starts the same way: a ticket hands you one string — a client reference, a booking id, a trace-id, a PNR — and a strong opinion about whose fault it is. The method that works is boring and always the same: route the identifier, widen it, build the timeline, and only then allow yourself a hypothesis.
· 5 min read
A list of things that are contracts without looking like one — an identifier a client holds between two calls, a documented error code, the difference between a field being absent, empty and null. Why adding is nearly free and removing is a coordinated release across repositories I do not deploy, and what it honestly costs to keep everything working.
· 6 min read
Review technique after a year of reviewing for six engineers: the three things a review is actually checking, the one thing it is not for, why every comment now says in its own text whether it blocks, and the four questions I ask of any change that touches money or state. No review-time or defect-rate figure was ever measured — what is countable is what the reviews left behind.
· 5 min read
Nobody learns ninety of anything. They learn one shape and then the exceptions — which is why a fixed module contract and two documented offer patterns are an onboarding artifact as much as an architecture. What the first week actually is: run the whole booking flow once, read one supplier module top to bottom, then change something small on a second one.
· 5 min read
What actually changed when the job went from "write the feature" to leading a six-engineer team and owning a multi-repo release train. The unit of work became a decision instead of a diff, review stopped being an interruption, and the fastest way to lose a week turned out to be answering a question instead of writing the answer down.
· 5 min read
The default is a relational store, Redis, a queue, Node and TypeScript — not because they are the best tools in the abstract, but because 3am is not when you want to be learning a datastore's failure modes. Then the one time the exotic choice was right, argued on its merits, and the test I use to tell the two situations apart.
· 6 min read
A queue buys exactly one thing worth having: a slow supplier stops being everyone's problem. It charges for that in instalments — ordering, retries that make idempotency your problem, messages that fail forever, and the state of the work spread across three stores that can disagree. A ledger of both sides.
· 4 min read
Four and a half years across backend, frontend and deployment — not as a badge, but because internal tools have no other engineer. What each side of the stack taught the other, what the breadth honestly costs, and why the person who can follow a request from a React table to a supplier's SOAP endpoint is the person who can find where it broke.
· 6 min read
In integration work the defect usually lives in a system you cannot read, so a log stops being a debugging aid and becomes evidence you may have to show a third party. What that changes about the design of the record — capture as it left, keep the body on a 200, make it re-firable — and the three constraints that stop the evidence from becoming its own outage.
· 5 min read
Documentation as leverage rather than bureaucracy, argued from artifacts that exist: seventy-odd runbooks, thousands of lines of runbook prompt, flow diagrams and user stories written back from code, and a table of contents where every entry carries its blast radius. Plus the section this site keeps insisting on — "what I am not certain of" — and why no hours-saved figure appears anywhere.
· 6 min read
A supplier is an organisation, not an endpoint. Certification is a conversation with someone who has their own release calendar; a bug you find in their system gets fixed on their schedule, so the report has to be good enough to act on without a meeting. On evidence as communication, writing for a reader who does not know your system, and estimates that have to contain somebody else's queue.
· 5 min read
The question arrives before anyone has read the supplier's documentation, and the documentation is not where the answer lives. What actually decides the estimate — which offer pattern the supplier fits, whether booking is idempotent, whether errors arrive as status codes or inside a 200, whether the sandbox resembles production, and whose calendar certification runs on — and the two-phase answer I give instead of a date.
· 5 min read
The dashboard that consumes your own API is the fastest API review available, and the specifics are what teach: a table whose identity row carries dozens of supplier-ID columns, three different reasons a screen can be empty, an error code that has to become a sentence someone can act on, and a money screen that must say which number is shown and which is charged. Plus the half nobody plans for — an internal tool is a production system with users who sit near you.
· 5 min read
The expensive mistakes are not the wrong ones — they are the wrong ones that look right for months. Four things I build for that: a mapping campaign of 11,953 rows written so it could be rolled back row by row, and was; a cost file where every figure says measured or estimated; a required "what I am not certain of" section; and agents whose stated job is to refute a finding rather than confirm it.
Showing 10 of 20