Case studies
Two decades of building and fixing e-commerce and custom systems. No client names and no logos here — this is anonymised — but the judgment behind the work is the part that matters, so that’s what these describe.
I’ve been building for the web since 2005. The clearest thing I can tell you about how the work holds up isn’t a figure — it’s that a custom CRM and CMS I wrote in 2009 is still in daily production use today. Built to be maintained and extended, not thrown away and rebuilt every few years. That’s the standard everything below was held to.
The system that outlived its replacements
The situation. A business whose day-to-day didn’t fit any off-the-shelf CRM. They’d tried bending their process around the tools, and the tools kept losing.
What was wrong. Generic CRMs modelled a sales process this business didn’t run. Forcing the fit meant constant workarounds, data in the wrong places, and staff quietly keeping their own spreadsheets on the side — the sign a system has already failed.
What I did. Built a CRM and CMS from scratch, together, modelled on how the business actually worked rather than how software vendors assumed it should. The important decision wasn’t any one feature; it was building it to be maintained and changed over years, because a bespoke system that can’t evolve is just a more expensive dead end.
What it changed. The workarounds stopped, and the shadow spreadsheets went away. More telling: fifteen years on, parts of it are still running the business every day — through staff changes, hosting moves and requirement changes it wasn’t originally designed for.
Booking where the rules were the hard part
The situation. A reservation and pilot-training scheduler for an aviation operation. On the surface, “a booking system.” Underneath, a constraint problem.
What was wrong. Off-the-shelf booking tools treat a slot as a slot. Here, a slot depended on aircraft availability, instructor availability, and where each trainee was in a required training sequence — all constraining each other at once. A calendar that doesn’t understand those rules just lets people book things that can’t actually happen.
What I did. Built the scheduling logic properly — the rules first, the interface second — and tested it against how the operation really ran, not against a tidy demo. The value was in the edge cases: the bookings the system had to refuse, and why.
What it changed. Scheduling stopped producing impossible combinations, and the rules lived in the software instead of in one person’s head.
Three systems that had to agree
The situation. A tourist agency running a custom website, a reservation system, an XML product feed and a CRM — four moving parts that all had to describe the same reality.
What was wrong. The storefront, the bookings and the back office each held their own version of the truth, and they drifted. Inventory and bookings that disagree overnight turn into overselling, support tickets and lost trust — and the failures always surface at the worst time.
What I did. Wired the pieces together with the boring, careful plumbing that integration actually needs — a resilient sync between the feed, the store and the CRM, built to handle partial failures and retries rather than assume everything always succeeds. The hard part wasn’t any single connection; it was making the whole thing trustworthy.
What it changed. The systems stayed in step. The 2am surprises stopped, because the integration was built expecting the things that go wrong instead of pretending they wouldn’t.
Client names and references available on request.