I build the web apps people use at work every day.

A trade show has a hundred moving parts. This was the attempt to keep them in one place.

The problem

Sign-up was long enough that people gave up halfway through it. And once they were in, working out who was worth meeting was still someone's manual job.

What I built

Registration, check-ins, meeting scheduling and lead capture, all in one place instead of across a pile of spreadsheets. I built the whole front end against about 120 endpoints.

The outcome

I reworked sign-up and drop-off fell by about 60%. Onboarding is a short conversation now: it turns what you say into a business profile, then suggests who's worth meeting.

• React
• React Query
• OpenAI

Taking someone's money in a browser is the one flow you don't get to be careless with.

The problem

State was spread across the app with a lot of boilerplate holding it together. Every change to the payment flow felt like it might break something two files away.

What I built

An internal tool for sales teams to manage leads and take payments without leaving the browser. The payment flow is mine, start to finish.

The outcome

Moving it onto Zustand cut the boilerplate and made the flow readable top to bottom. It stopped being the part of the codebase people were nervous about touching.

• React
• Zustand
• React Query

One bundle, several teams shipping into it, and load times that only went one direction.

The problem

It was a single app that several teams were all shipping features into. The bundle kept growing and the portal kept getting slower to open.

What I built

A portal where agents buy policies and put together benefit illustrations for their clients, in one place.

The outcome

Splitting it into micro-frontends brought load times down noticeably. React Query caching handled the rest, so the data stopped feeling like it was being fetched.

• React
• TypeScript
• Micro Frontends

Twenty-five pages, ten languages, and nobody waiting on a developer to change a word.

The problem

Every copy change, however small, went through a developer first. Which really meant it went into a queue.

What I built

A corporate site of around 25 pages across ten languages, built so marketing could edit it without asking anyone.

The outcome

I modelled the content types and the reusable blocks behind them. Marketing edits the whole site themselves now, and the pages still load fast.

• Gatsby
• Strapi
• GraphQL

Mostly a performance job. About a third of what we were shipping turned out to be unnecessary.

The problem

The bundle had quietly grown heavy, and it showed worst for agents on slow connections, who could least afford to wait on it.

What I built

A tracker for exam scores, retakes and attendance across training batches.

The outcome

Code-splitting and trimming what was actually being sent cut the bundle by about a third. It went back to feeling immediate.

• React
• Zustand

Several portals, different users, one set of parts underneath all of them.

The problem

Every portal needed to look and behave the same way. Building the same interface a fourth time by hand was not going to hold.

What I built

Policy management portals with maps and dashboards, each one shaped around a different kind of user.

The outcome

I built the component library the whole thing sits on. New portals get assembled from parts that already exist and already agree with each other.

• React
• Tailwind
• Radix UI

No interface on this one. Just routes, a hierarchy, and ratings that keep up.

The problem

The catalog goes category, then subcategory, then product. The URLs had to stay readable all the way to the bottom of that tree.

What I built

A product catalog API, built as the backend developer on the project.

The outcome

Slug-based routing across the full hierarchy, with ratings that recalculate the moment a review lands rather than on a schedule.

• Node.js
• Express
• SQL