MaxRec · 2026 · Sports tech · Solo designer · Built with AI

Designing a boxing league’s platform with AI, from my direction to working code

Problem

Tournaments ran on 3 different tools

Maxliga ran sign-ups and payments across Excel, WordPress and Facebook. Sometimes a fighter paid and still wasn’t on the list.

My role

Solo designer, with the founder and 1 backend developer

Research, product design, and the frontend built in Claude Code.

Outcome

1 week

From my Figma screens, without every flow, to the final screens in code. My frontend went to production, and in the retest organisers got around in half the time.

one live tournament, sign-ups to bracket · sample data

AI was in almost every step. The interesting part is where I let it lead and where I took over.

The problem

Organisers managed sign-ups and payments across Excel, WordPress and Facebook. Checking who’d signed up, who’d paid and who was actually registered meant manual checks, again and again. Sometimes a fighter had paid and still wasn’t on the list.

who’s paid · one filter, one click · sample data

The founder wanted more than a tidier admin. She asked for a ranking in the spirit of BoxRec (boxing’s big records and rankings site), with points thresholds that earn rewards: a T-shirt, a gala ticket, free entry. The business goal was more entries per fighter across the season.

Fighters wanted it too. The ones I interviewed already followed BoxRec, and many of them said a ranking would make them want to enter more.

So MaxRec had 2 jobs: a dashboard that runs a tournament in one place, and a fighter website where every fight counts towards something you can see.

What I worked with

I used 8 tools, and each one had a narrow job. The 3 sections below explain the calls behind them.

Figma Make My first pass. I rebuilt the developer’s early features and let it generate screens, until its taste started leading.

Figma Where I mapped the flows and designed the key screens myself, so the visual direction was mine.

FigJam Organisers sorted the dashboard’s features into 3 or 4 piles. Their piles became the navigation.

Claude + Figma MCP Extended my key screens into the full set and cleaned up the design system’s variables and naming.

Claude + Mobbin Pulled proven patterns for signup approval and matchmaking.

Claude in Chrome Ran the competitor audit: MaxRec against BoxRec and the tools organisers already used.

Claude Code Built interactive flows for both surfaces on sample data, working from the project folder. About 50 screens in a week.

Loom Walkthroughs of how the flows behave, recorded for the developer.

01 · Taking the visual direction back from AI

I started fast. I rebuilt the developer’s early features in Figma Make and let it generate screens. It got me moving, and it had its own taste: bright primary colours that pulled attention from the fight data, random extra elements, the odd screen broken mid-edit.

I could have kept prompting and correcting. I split the work instead: I mapped the flows in Figma and designed the key screens myself, so the visual direction was mine.

Then AI came back with a narrower job: extending my key screens into the full set, inside the direction I’d set.

02 · A project folder Claude worked from

I kept a MaxRec folder that Claude Code worked from, and I updated it every time a decision changed.

Competitor audit.md MaxRec against BoxRec and the tools organisers already used. I ran it with Claude in Chrome.

Interview notes.md What organisers and fighters told me, in their words.

Goals and the old way.md What the founder wanted from the ranking, and how a tournament ran on Excel, WordPress and Facebook.

Design tokens.json So every generated screen started from my colours, type and spacing.

Claude worked from the project’s current state, so I wasn’t re-explaining it in every prompt.

I reviewed every screen myself, and that’s where I caught Claude’s wrong calls. For entering fight results, Claude Code built a separate page. On fight day the organiser is stressed and needs something quick, so I made it a pop-up over the bracket, and she never leaves the screen she’s running the tournament from.

03 · Handing off working code

The developer had my Figma files from day one. But most of MaxRec is behaviour: registration states, approvals, groups, pairing. Static screens explain that badly, and specs for every state would have been long and still incomplete.

So I built interactive flows for both surfaces in Claude Code, on sample data, and recorded Loom walkthroughs of how they behave. It took about a week, with a lot of iteration. The cost: sample data meant the developer still had to review and adapt the code while he built the backend.

Product decisions from research and testing

I tested with 3 organisers and 2 fighters, all from earlier tournaments. They turned up 3 problems, and each one changed the design.

The navigation follows a tournament. The early dashboard grouped features by topic, and organisers kept losing the tournament they were working on. In a FigJam exercise I asked them to sort the features into 3 or 4 piles. Their piles followed a tournament from setup to fight night, so the navigation does too. In the retest I timed them, and getting around took half as long.

Pairing stays with the organiser. The founder pairs on weight and gender, then on skill and what she knows about each fighter. She also seeds the bracket, putting 2 strong fighters at opposite ends so they meet in the final. Automatic pairing by weight would happily put them in the first fight.

weight groups · drag fighters in · sample dataGrouping stays manual. In testing, organisers didn’t realise they could drag, so a line of microcopy above the list now tells them to.

So she places her top seeds by hand, and the draw fills the rest at random.

the bracket · seeds by hand, then the draw · sample dataThe top 2 seeds go on opposite sides by hand, so they can only meet in the final. The draw fills the other slots at random.
fight day · score in, bracket moves on · sample dataOn fight day the organiser starts the tournament and enters each score in a pop-up over the bracket. Winners move into the next round on their own.

The third problem was on the fighter side. Fighters who’d entered before had to type in their age and height again for every tournament. Now registration keeps their basic details and only asks for weight again, since that can change.

Decisions

Four calls, what each replaced, and what it cost.

  1. Designing the key screens by hand

    cost · Slower than generating them

    instead of Prompting Figma Make until it looked right

  2. A project folder Claude worked from

    cost · Updating it every time a decision changed

    instead of Re-explaining the project in every prompt

  3. Handing off working code

    cost · Sample data the developer had to adapt

    instead of Static screens and specs

  4. Letting the organiser pair and seed by hand

    cost · Slower for big groups

    instead of Automatic pairing by weight

50%Less time getting around, timed with 3 organisers in the retest

My frontend went to production, and the developer kept most of it (I’d estimate around 80%). MaxRec ran its first real tournament in autumn 2026. The project paused after that for reasons on the league’s side, with a restart planned for the end of 2026. When it’s back, the number I’d watch is entries per fighter per season.

~50Screens across 8 flows, for organisers and fighters
1 weekFrom my Figma screens to the final screens in code

Tested with 5 people: 3 organisers and 2 fighters, all from earlier tournaments.

Reflection

Next time I’d start with the key screens by hand. Generating first cost me time pulling AI’s colours back towards a direction I hadn’t set yet. And I’d measure more: how much code survived, and whether the ranking really brings fighters back.

This is how I like to work now: I set the direction, AI does the heavy lifting, and the developer gets something that already behaves. If your team builds like that, say hi.

More work