PLATE 06
Selected client platforms
Three client platforms where the engineering was integration and data work: scheduled synchronisation, feed normalisation and editorial tooling
- ROLE
- Sole developer, agency delivery
- STACK
- PHP · JavaScript · MySQL · Scheduled REST, SOAP and XML feeds · WordPress
BRIEF
Client and agency delivery means shipping to deadline, against stakeholder complexity, at real traffic, for organisations whose sites are operationally load-bearing rather than promotional. Three are drawn here. The engineering in them is integration and data work: scheduled synchronisation, feed ingestion and editorial tooling. The platform underneath is incidental to what the problems were.
One source of truth, and it is not the website
Stakeholders maintain their own business listings in the Tempest CRM. Scheduled synchronisation regenerates the corresponding content records, and the site has no local override.
The obvious feature request is an editorial override in WordPress: a way to fix a listing that comes back wrong or badly written. It was not built. The team elected to monitor and correct at the CRM level instead, which keeps a single authoritative record rather than creating a second one that drifts. An override layer solves today's bad listing and guarantees a permanent reconciliation problem: every subsequent sync has to decide whether the local edit or the upstream record wins, and there is no answer to that question that is right every time.
A constrained palette
Each custom post type exposes a block set carrying only the fields relevant to it, rather than the full editor palette.
This was a client requirement rather than a call of mine. What it produces structurally is a block library per content type: editors working on a garden page cannot reach fields belonging to an event, and the content model is enforced by what the interface offers rather than by convention or training.
CONSTRAINT
On client work you own almost nothing. Not the data, not the brand, not the content model, and frequently not the decision.
Two clocks, one board
The scheduled flight list arrives once a day, as an XML file over FTP. Gate, status and delay changes arrive separately on a live feed, polled frequently. Both had to resolve into a single arrivals and departures board.
The two sources disagree by design. The daily file says what is supposed to happen; the live feed says what is happening. Normalising them into one schema means deciding, field by field, which source is authoritative. It also means deciding what the board shows for a flight the schedule lists and the live feed has not yet mentioned, which is not the same as a flight that is on time.
Caching sits directly against that. It has to be aggressive enough to survive an airport's traffic and shallow enough that a delay reaches the traveller while it still matters. That tension, rather than either feed on its own, is the engineering in this project.
CONSEQUENCE
What you own is whether it holds up afterwards. The method that came out of that work is to ask yourself every question and answer it before it surprises you later. Not a process, and not something a client ever asks for. It is the difference between a build that survives its first real season and one that has to be explained.
NEXT PROJECT
Driftborn
Ships that channel the universe. A 2D space shooter with planar gameplay and angled 3D presentation.
