I build web applications and the systems behind them. APIs, data platforms and integrations in TypeScript, Node and Laravel, with React and Next.js on the front.
Node and TypeScript services, REST and GraphQL API design, relational schema modelling, background jobs and queues. Built around the assumption that the data will still need to be correct and queryable in two years, not just on launch day.
End to end builds: React and Next.js on the front, Node or Laravel behind, MySQL underneath. Auth, dashboards, admin tooling and the unglamorous internal screens that take a manual job off somebody's desk.
Pipelines between platforms that were never designed to talk to each other. ERPs, warehouse systems, third party APIs and legacy exports. Idempotent, observable, and built to survive the day a supplier changes their payload without warning.
Systems that collect continuously from many independent sources: IoT devices, scheduled feeds, webhooks. Ingest that tolerates gaps and duplicates without polluting the dataset, and dashboards that people actually make decisions from.
The domain I know best. Custom Shopify apps and checkout logic, order and inventory sync, theme architecture and migrations on large live catalogues. Useful whether you need it directly, or just want someone who has shipped against a platform with real money moving through it.
End to end and unit coverage on the logic that touches money or stock, Dockerised test suites, Core Web Vitals work on the front end. A rounding error is not a design problem, and it does not get found by looking at the page.
The API behind a UK water technology company's monitoring platform, which collects rainfall and rainwater capture data from sites across the country and turns it into evidence that water companies and project leads can act on.
A large number of independent devices reporting on their own schedule, a schema that has to stay queryable as the estate grows, ingest that tolerates gaps and duplicates without polluting the dataset, and dashboards people make funding decisions from. This is the project that set how I have approached every system since.
A bundle builder written from scratch for a client whose catalogue no off the shelf product could handle. Customers assemble a fixed price box from any combination of variants, and a checkout side function expands that single bundle line into its component products server side rather than in browser JavaScript.
The interesting problem was money. Splitting one bundle price across a variable number of component lines is where most implementations quietly lose or invent pennies. This one does the split in integer cents with explicit remainder distribution, locked down by fixture based regression tests that run against the compiled WASM build rather than a mock of it.
When stock lives in three systems at once, the three will disagree, and usually nobody notices until something oversells. This is tooling that pulls all three, compares them on a schedule, and surfaces the differences as an actionable list rather than a raw export nobody opens.
The work is less about the diff and more about everything around it. Matching identifiers that were never entered consistently, deciding which source wins for which record, handling a partial feed failure without corrupting the data, and keeping an audit trail of every correction so the finance side can trust the number.
HighCohesion is an integration platform for fast growing retail and apparel brands. I design and maintain the data pipelines that connect a brand's storefront to the rest of its stack: ERPs, 3PLs, warehouse management systems and third party platforms. When a business scales quickly, the gap between its systems turns into missed orders, wrong stock and manual work that grows faster than the revenue. Closing that gap is the job, and it is production backend work on real volume every day. I also led the AI enablement of their support desk product, including an MCP server and the platform migration behind it.
Migrated one of Britain's oldest fragrance houses onto a new theme architecture, recreating their existing design almost exactly. Every section and custom block was rebuilt from scratch against the new schema, on a live multi region catalogue, with a subscription flow that had to keep working throughout.
View live site ↗
Replaced the platform's native product recommendations with a bespoke algorithm modelled on how the brand actually sells, weighting pattern repeat, material and room type. The platform has no concept of any of those, so the logic and the data model behind it were built specifically for them, alongside mobile and performance work across the front end.
View live site ↗Things built outside of work, mostly to learn something. Some are finished, some are deliberately not, and they are live unless noted.
A full stack app for tracking things you have lent out, with scheduled reminders and notifications. Auth, ownership rules, and a notification system that had to be idempotent so nobody got the same nudge twice.
Marketing site for a local removals, handyman and van service. Built and shipped end to end: content structure, booking enquiry flow, and the mobile performance work that matters when most of the traffic arrives from a phone.
Marketing site for a hospitality business in Dartmouth. Designed and built to sell a place rather than a product, so the work went into imagery, pacing and getting people to the enquiry point without friction.
Front end for a rainwater harvesting and environmental outreach company, sitting in front of the same monitoring platform I built the API for. The public facing side of a system whose real complexity is in the data behind it.
A dashboard fed by sensors reporting pond temperature and depth over MQTT, with alerting on spikes. The small version of the ingest problem: unreliable devices, irregular reporting, and readings you cannot simply trust.
An experimental UI using text to image and video to video models to build a video game style character selection screen. Mostly an excuse to work out how to keep a generative pipeline feeling responsive.
An end to end testing setup that runs the same way locally and in CI, containerised so a passing suite on a laptop actually means something. Built while working out what is worth asserting and what is just noise.
A dashboard letting schools measure, record and track their own rainfall data, built as an outreach front end onto the same monitoring stack. Simple enough for a classroom, strict enough that the readings stay usable.
A concept storefront for a fashion label that does not exist, somewhere between ancient armour and futuristic couture. An exercise in motion design and art direction rather than commerce.
I came into development through full stack work and web education, and I have stayed a generalist on purpose. I like problems that run the whole depth of a system: something a person clicks at the top, a schema decision at the bottom, and a few services in between that all have to agree with each other.
Most of my professional work has been in ecommerce, which is a good place to learn that discipline. A store is never one system. It is a storefront, an inventory source, a fulfilment partner, a finance system and a handful of third party tools, and most of the real problems live in the gaps between them. That is true of any business with more than one piece of software in it.
I care about the things that are expensive to get wrong later: schemas you can extend, integrations that fail loudly instead of silently, and tests on anything that touches money or stock. Outside of work I build small things to keep learning, which is what most of the projects above are.
Languages & frameworks
TypeScript · JavaScript · Node · React · Next.js · React Router · PHP · Laravel · Liquid · HTML & CSS
Data & infrastructure
MySQL · Prisma · REST & GraphQL API design · AWS · Docker · scheduled jobs & queues · Firebase · Git & CI
Practice
Systems integration · ingest & reconciliation · audit logging · Vitest · Playwright · performance & Core Web Vitals
Open to full stack and backend work, contract or permanent. Happy to talk through a build, an integration that is not behaving, or a system nobody quite wants to touch any more. If you are not sure whether what you need is a front end change, an app, or something further back in the stack, that is usually a good conversation to have early.
