A few projects that show how I work — not just what was built, but the decisions and trade-offs behind them. Public projects link out; NDA work is described by factual scope only.
05 / Case Studies
Where to start
Six situations people usually call me about
Enquiries almost never arrive as a spec. They arrive as a symptom: a menu that is out of date by Tuesday, a checkout that leaks, a spreadsheet quietly holding the business together. Pick the one that sounds like your week — each path opens either the closest piece of proof or the work that fixes it.
Prices change on Tuesday and the printed menu still says otherwise on Friday. Tourists photograph the card and translate it themselves. Every small correction turns into a message to whoever built the site — and waiting.
A menu the venue owns outright: edited in minutes, live immediately, readable in the guest's own language straight from the QR code on the table. Payments and booking get wired in only where they earn their keep.
wMenu — a multi-language QR-menu SaaS with Stripe subscriptions, built end to end.
Paid traffic lands on a product page that takes four seconds to become useful. The checkout loses people somewhere between the basket and the payment step. And the WooCommerce build that was fine three years ago now flinches every time a plugin updates.
A storefront that renders fast, product pages structured so shoppers and search engines read the same thing, and a checkout cut back to the steps that actually convert — usually a headless frontend in front of the WooCommerce you already run.
Starts with an audit: what is costing you seconds, and what is costing you orders.
The product does thirty things well, which is exactly the problem. The person signing the contract runs a clinic, not an IT department, and bounces off a feature list. Meanwhile the interface drifts a little further with every module that ships.
A marketing layer that leads with what a clinic actually feels — fewer no-shows, less admin, billing that reconciles — and a product frontend built on shared patterns, so schedules, patient records and treatment plans still look like one product a year later.
dr100 — marketing site and product frontend for dental practice management software.
Someone retypes a figure at month end and the report is wrong downstream. Nobody is certain which fields are validated. And nobody wants to change the code near billing, because there is no test that would say if it broke.
A typed application where invalid data is hard to enter in the first place, the paths that touch money are covered by tests that run on every change, and the screens work by keyboard for the people who sit in them all day.
A finance subscription-management rebuild — under NDA, so technical scope only.
A lead arrives by email, gets typed into the CRM, then into a spreadsheet, then someone chases the invoice by hand. Nothing is broken exactly. It just costs a day a week, every week, and the person doing it is usually the one you can least afford to lose.
Forms, CRM, billing and reporting connected so a record is entered once and travels on its own — with the few steps that genuinely need a human left visible instead of buried in an inbox.
The same muscle as the finance CRM and the wMenu back office.
The engineering is not the hard part. The hard part is a website that makes a specialist data practice look like every other consultancy — or a data tool where a dependency is rendered as a row of identifiers nobody can follow to its source.
Either a site structured around what the company is genuinely expert in, so those pages can rank and hold up in front of engineers and buyers alike — or an interface where a data graph becomes something you can trace with your eyes.
GetInData — company website built from scratch on React and Gatsby.
Behind the five case studies sits a decade of other work: medical portals and clinic systems, an investment application, a moderation panel, German bakeries, a dog-friendly hotel finder. Listed factually — product context, my part in it, the stack.
