Systems
Platform and transactional architecture
Most platforms do not fail at the interface. They fail because the transaction was never modelled — so every new requirement adds a branch, and the branches eventually contradict each other.
A feature that should take days takes a sprint, and nobody can say why.
The same order can be in two states at once, depending on which screen you ask.
The platform is fine until the campaign lands, and then it is not.
Two products were merged and now share a schema neither of them fits.
- 01
Transaction and state modelling
We write down the states an order, an account or a booking can legally occupy, and the transitions between them. Most of the defects in a mature platform live in the transitions nobody named.
- 02
Domain invariants before features
What must remain true regardless of release — balances that reconcile, bookings that cannot overlap, prices that cannot be negative. These become constraints in the system rather than conventions in a document.
- 03
Consistency and failure isolation
Where the system must be strongly consistent and where it can settle later, which failures may propagate and which must be contained, and what the platform is allowed to do when a dependency is down.
- 04
Behaviour under load
Load is a design input, not a later optimisation. Which paths must stay fast when the rest queues, where the limits sit and who they apply to, what is cached and what may never be, and which features are isolated so that the busiest one cannot take the others down with it. We build this into our own products — the group that fails is one group, never the platform.
- 05
Unifying several products on one core
Companies that ship three products usually maintain three half-domains. We define the shared core and the seams, so the products stay separate where they differ and stop diverging where they do not.
- 01
A state and transaction model of the domain, written so a non-engineer can argue with it
- 02
An architecture definition: boundaries, contracts, consistency and failure behaviour
- 03
A migration path from the system you have to the one described, in shippable stages
- 04
The invariants, expressed as constraints and tests rather than as documentation
Invariant
The domain model is the product. Everything above it is an interface to it.
- Do you rewrite the platform?
- Rarely, and never as an opening move. A rewrite is the most expensive way to discover that the original model was the problem. We model first, correct the model in place where that is possible, and reserve replacement for the components that cannot be corrected.
- How long does an architecture engagement take?
- The definition itself is usually four to eight weeks depending on the number of products involved. Implementation runs longer and is staged so that value lands before the last stage.
- Do you work with our existing engineering team?
- That is the normal case. We operate close to the CTO and the core team; the architecture has to be something they can carry after we leave, or it was theatre.
Each one carries what it is good for, what it is proven on here, and the point at which it stops working. We take no vendor commissions on any of them.
- Shopify
- Hosted commerce: Shopify runs the checkout, the payment compliance and the uptime; the theme and the data model are yours.
- PostgreSQL
- A relational database with real transactions: either every part of a change lands or none of it does.
- Docker
- Process isolation with the filesystem and dependencies pinned, so a program runs the same on a laptop and on a server.
- TypeScript
- A typed layer over JavaScript: shapes are checked when the code is compiled, and erased before it runs.
- Next.js
- A React framework that decides, per route, whether a page is rendered once at build time or computed on every request.
- Supabase
- Managed PostgreSQL with an authentication service, file storage and a generated HTTP API in front of it, addressable directly from a browser.
- Prisma
- Prisma is a schema definition language for relational databases that generates a typed client and emits versioned SQL migration files.
- Vercel
- A hosting platform built by the authors of Next.js, where a push to a git branch becomes a globally cached deployment whose per-route cache behaviour is taken from the framework's own build output.
- Cloudflare
- A global proxy network that terminates traffic close to the visitor, plus Workers — a runtime that executes code at those same locations rather than at an origin.
- Turborepo
- Turborepo is a task runner for JavaScript monorepos: it reads the dependency graph between packages, runs tasks in the right order, and skips work whose inputs have not changed.
- Python
- A general-purpose language whose value in this practice is narrow and specific: the reference implementations for reading and writing awkward archive and binary formats — .docx, .xlsx internals, font tables — are written in it.
- Vitest
- A test runner that reuses the project's own Vite build configuration, so tests run through the same transform and the same module graph as the application.
- Vite
- Vite is a development server and build tool: it serves source files as native ES modules while developing, and bundles them with Rollup for production.
- Sentry
- Sentry captures unhandled errors and slow transactions from running software, groups them into issues, and ties each one to the release and the commit that introduced it.
- Ziina
- A UAE payment processor, licensed by the Central Bank of the UAE, that takes cards and wallets through a hosted page created by a single API call.
- WordPress
- The PHP content management system behind 40.7 per cent of all websites, which assembles every page at request time from a core, a theme and an unbounded number of third-party plugins.
- Tilda
- A hosted website builder where pages are assembled by dragging pre-made blocks, and the platform serves the result from its own CDN.
- Framer
- A hosted site builder in which the design canvas is the source of truth: pages are drawn, and Framer renders and serves them from its own infrastructure.
- Document extraction
- Reading the fields off a photographed document — passport, Emirates ID, driving licence, trade licence, vehicle registration, insurance, an odometer, an invoice — and filing them against a record.
- Model Context Protocol
- An open protocol that lets an assistant call tools and read live data directly, instead of being handed an excerpt somebody pasted.
- End-of-life runtimes
- A language runtime or framework version whose maintainers have stopped issuing security fixes — still running, still serving traffic, no longer receiving patches.
- SQL
- The language a relational database is actually configured in — tables, constraints, indexes and access policies.
- JavaScript
- The language of the browser, run on the server too — used here without a type layer on top of it.
- From a brief to work somebody has accepted
- A piece of paid work, travelling from the sentence that started it to the moment the buyer agrees it is finished and can carry it without the supplier. 6 steps, 6 known jams.
- From something breaking to somebody confirming it works
- An outage, from the moment the system stopped being correct to the moment a person has checked that it is correct again — including the parts that happen before anybody has touched a keyboard. 6 steps, 6 known jams.
Not a specification — the system as it is, with the parts everyone works around. The first conversation establishes whether the constraint is architectural or organisational, because the two look identical from the inside and only one of them is fixed by building something.