Building with AI
16 May 26 · ai
This Saturday there was a padel tournament at my club, and I decided to finally build an app I'd had in mind for some time to manage these kinds of events. With less than a week available, I decided to develop almost the entire project using AI as a way to test what the full development process with Claude would look like.
The brief
The first step was the brief. Starting on Monday, the idea was to have it ready by Wednesday so I could share it with the club in case they wanted to use it.
I started with a brainstorming session in the Claude web app, where I (or rather, we) defined the functionalities and tech stack.
I already had the tech stack and a rough idea in mind, but putting it on paper helps, otherwise I branch out quickly.
This is what we landed on for v0:
- two user types: player and admin
- players log in with a code and can view their points, match results, and upcoming matches
- admin adds results and confirms classifications
The tech stack is technologies I've used before, multiple times: Next.js, TypeScript, Tailwind CSS, Supabase, Shadcn, Better Auth.
One last thing: I shared the schedule, rules, and draw PDFs with Claude to put together a reference document covering the logic and constraints for the app.
The Design
In a regular project I would search for inspiration across different sources and put together a wireframe and mid-fidelity design in Figma. This time I used Claude Design instead. I fed it the brief, requested the screens I needed, and explained the general design direction I like to follow: minimal and functional.
The result was 9 screens, 7 for the player and 2 for the admin. Most of it reached production with only minor adjustments, which honestly surprised me. These hi-fi designs used around 80-90% of my Claude Design weekly limit. The design spec I generated afterwards to hand off to Claude Code used up the rest.
Development
I've already used Claude Code for some development but for this project I wanted a 95/5 ratio, Claude doing 95% of the work, me doing the rest. I began with the initial project set up: installing dependencies, configuring Next.js, leaving everything ready to build on.
One thing worth raising here: Next.js ships with its own AGENTS.md, which points agents to check for the latest version. I had to remind Claude a couple of times about the recent version changes. I then generated a CLAUDE.md based on the project reference document, which gives Claude Code a single source of truth for the project's logic and constraints throughout development. As part of the setup I also added the Shadcn skill and MCP server, which made a noticeable difference in how Claude generated the UI components.
I split the work into two phases: structure and design. The idea was to get everything working first, then style it. My first instruction was to start with auth and everything admin-related. Every request was deliberately bite-sized, never "build the complete admin section with X, Y and Z" but rather "build X feature", test it, then move on. That way I could follow what was being generated.
I only switched to Auto Mode for the standings and brackets logic, then went back to normal. I still prefer to review what's being generated before it ships.
Git was essential, both to avoid unwanted changes and to roll back when needed. I ended up with 8 branches and 30 commits.
For the design phase, I fed Claude Code screenshots from Claude Design alongside the HTML of the designs, with a prompt explaining what to keep and what to drop.
Setbacks
I'd planned to have everything ready by Wednesday, but ended up pushing it one day. The issue was a testing problem: admin login worked fine on my desktop but failed on mobile when connecting through the same network. Debugging took longer than expected.
Claude kept trying to modify proxy.ts and various components, but the code itself was fine. It was looking in the wrong place. The actual problem turned out to be my IP missing from allowedDevOrigins.
Curiosities
On Thursday, after the project was live on Vercel, I noticed an issue with admin login: it would get caught in a redirect loop until it crashed. I'd just left home, so I opened Claude on the iPhone app and asked it to fix it from there.
The first thing it tried to do was rename proxy.ts to middleware.ts. I cancelled it as soon as I realised and told it to check the Next.js 16 docs again. It then corrected the route guard in proxy.ts and opened a PR, which I merged from the GitHub app. Didn't even need a computer to add some code.
Thoughts
- Claude Design genuinely surprised me. I'll definitely use it for my upcoming client project.
- I feel somewhat lost when Claude generates a lot of code at once. I tend to want to know what everything does, which is a bit of a learning curve. I reminded myself that in big projects I never know every line anyway. Giving Claude clearer structure upfront about where things should live would make it easier to trust Auto Mode more.
- Prompting matters for token efficiency. The design spec that used up my remaining quota could have been much leaner if I'd asked more precisely, when I checked it I found details completely unrelated to the design.
- Claude Code sessions don't share memory, which caught me off guard a few times. A prompt I found really useful was asking Claude to analyse the current state of the project, it brought the context up to date and helped surface what was missing. I also used that response to update CLAUDE.md.
- Claude struggles with very recent versions. I had to tell it at least four times that we were on Next.js 16.2.6 and that I was certain it was correct, linking to the docs each time.