Engineering
The software I build runs where I am not standing: a phone in a guest's pocket, a browser in a consulting room, a machine in another country at three in the morning. When something breaks there, nobody from engineering is nearby. The discipline has to travel with the code.
Everything I build rests on three habits. Each is stated twice — once for the engineers who will inspect the work, and once for the people who pay for it.
For engineers
I practise test-driven development. Behaviour is specified as an executable test before the implementation exists, and the suite is the contract. Coverage is enforced per file rather than in aggregate — a healthy-looking total once hid the most important module in a system at zero per cent, so no file ships untested. And there is exactly one definition of “does this pass”, run identically by the pipeline and by a person, because two versions of the truth is how green builds come to mean nothing.
In plain terms
Before any code is written, what “working” means is written down in a form a machine can check — automatically, for as long as the software lives. Written documentation goes quietly out of date and nobody notices. A test cannot: the moment it stops being true, the build fails.
For engineers
I practise domain-driven design. The core is organised into bounded contexts named after the business, whose aggregates own their invariants and perform no input or output. The domain touches no database, no framework, no network, not even the clock: every timestamp is passed in, so any moment in time can be tested. This is not a style guide I hope people follow. The layering rule is itself a test, and one convenient import fails the build.
In plain terms
The code is organised around the words your business already uses — a booking a guest makes, a tour a visitor walks, an appointment a practice keeps — rather than around databases and servers. Someone who runs the business could read the names inside the system and recognise their own work in them. The plumbing, which is to say storage, networks and payment processors, sits in a ring around that core, so any of it can be replaced without disturbing what the software means.
For engineers
SOLID applied rather than recited. Dependencies point inwards through narrow, structurally typed ports: no fat interfaces, no god objects, and a component that stores files cannot reach the customer records. Every port has at least two implementations, and substitutability is not assumed but tested — each adapter passes the same contract suite, so an in-memory fake and a cloud service are indistinguishable to the code that calls them.
In plain terms
Each part of a system — the payment processor, the place files are kept, the service that answers a question — sits behind a plain socket, the way an appliance sits behind a wall plug. Every one of them has an inexpensive stand-in, so a whole product can be built, demonstrated and tested on a laptop with no cloud account and no bill. And where a stand-in could mislead, since a test payment screen looks exactly like a real one, it is required to say so to the person looking at it.
None of this is preference. Every rule was bought with a specific mistake: the linter that gave two answers depending on who ran it, the untested file hiding behind a healthy average, the runbook that promised a setting no code had ever read. The three habits carry one lesson between them. A rule that lives in prose, or in someone's head, decays; a rule that lives in an executable check does not. So every promise that can be turned into a test becomes one, and the machine holds me to it.
This is what a client is buying alongside the software itself: not only a system that works on the day it is handed over, but one whose promises are checked again every time it changes — including by the engineers who come after me.
It governs everything I make, whether the work is a commissioned build, the prototypes in the lab, or my own products. The case studies and the writing are where it is shown in detail.
Start a conversation