I build fast, accessible web apps for startups and small teams.

The problem

Players guess at builds. The numbers they need are spread across patch notes and item pages, and they change every patch.

What I built

A workshop with the current patch's champions, items and runes. You put a build together and it runs the whole combo. Where an effect isn't modelled yet, it says so rather than guessing. Behind it sits an API on AWS with its own database, Google sign-in so players can save and share builds, and a job that picks up each new patch and checks its data before it goes live.

What it means for players

The damage maths is tested against numbers I worked out by hand, so the damage you see is right. Over 800 automated tests run before each release, and each new patch's data goes through the same checks before it goes live.

The problem

Altra sells to care groups, but families and care staff read the site too, often on a phone. The site had to make the case to buyers in English and French and stay easy for everyone else to read.

What I built

The current helloaltra.com, the website that presents Altra's platform. It has pages for each group Altra serves, each product area, testimonials, data security and the team's mission, all in English and French, with a link to book a demo. The platform itself is Altra's own.

How I made sure it worked

Accessibility checks on every page, and a mobile layout for each section, so a relative on a phone gets as much from the site as a buyer at a desk.

More screens

The problem

Most recipe sites start with the dish. Gumbo started with the fridge, so the search had to be quick to fill in and forgiving about what you typed.

What I built

As a contract React developer on Gumbo's team, I built the ingredient search, saved collections and the screens around them. I fitted them into the existing codebase rather than rewriting it.

How I made sure it worked

Component tests, TypeScript throughout, and testing on real phones. The product has since closed; these screens are rendered from its code with the back end switched off.

More screens

The problem

34 books spread across stores, and no home of his own. Whatever I built, he had to be able to run it.

What I built

A library of every book, from African history to his pig-farming guide, grouped into three themes with links to buy. Readers also get answers to the questions they ask. I built the front end and the back end behind it: the book data, a mailing list readers confirm by email, and a simple admin area so he can add books himself.

How I handed it over

Short written notes and one session showing him how to add a book.

More screens

Where it's at

It runs every day for me on real fixtures, and I'm checking its picks against results before anything goes public. Behind the screens, a daily data pipeline pulls in fixtures and stats, builds the day's card, refreshes it before kick-off and settles each line against the result the next morning. There's no launch date yet. The screens here are the signed-off designs, not the version running today. I'll write it up properly once it's public, with real results rather than promises.

More screens