PaintRack.
Designing and building a mobile app end-to-end with AI.
- Role
- Design & build
- Platform
- iOS · Android
- Stack
- React Native · Expo · SQLite
- Partner
- Claude · Figma MCP
Prologue
This case study isn’t really about the app. It’s about the work that produced it.
PaintRack is a premium mobile app for serious scale modellers. It catalogues four paint brands — Tamiya, AMMO by Mig Jimenez, Vallejo, and Mr. Hobby — tracks personal inventory, generates shareable shopping lists, and includes an AI assistant for mixing recipes and weathering technique advice.
I’m a designer with around fifteen years in the craft and seven focused on digital products. Strong on visual and strategy. Not a developer — not professionally, not by training. PaintRack was the project where I tested a question I’d been circling for two years: can a senior designer with no professional development background build a real, premium-quality product app end-to-end by using AI fluently?
Not vibe-code a prototype that breaks the moment you scroll past the first screen. A real app, with thought-through strategy, a defensible design system, and a build that holds up under the bench-test of an actual hobbyist during an actual modelling session.
The answer is yes — but only if the AI work gets the same rigour as any senior design engagement.
Process metrics. The app is pre-launch; business outcomes will land when it ships.
5
Strategic documents
Produced before a line of code was written.
40+
Pages of design spec
Built in three working sessions.
2
Personas as filters
Only the rejection-test pair made the cut.
1
CLAUDE.md file
Runs the entire build.
Phase one · Foundations
Strategy before anything else.
Rejected
- Eight brands at launch
- Social features
- v1 monetisation
- Dark mode as an option
The temptation with AI is to jump to outputs — wireframes, code, palettes. Most AI projects fail there. The work looks fast because the outputs arrive in minutes, but the foundations underneath them are arbitrary, and the product never escapes feeling like the sum of its prompts.
I started with a full v1.0 strategy document. Vision. Problem. Target user. Scope. Non-goals. Technical architecture. Roadmap. Risks. Success metrics. I worked through it with Claude as a sparring partner — write a section, push back on the framing, ask Claude to argue the opposite, ask what a CPO would push back on. The output is mine, but pressure-tested before any visual work began.
The strategy forced early constraints. Four brands at launch, not eight. No social features. No monetisation in v1. Dark mode as default, not as an option. Those constraints became the rails for everything that followed — without them, the build phase would have produced a wider but shallower product, the worst kind of personal project that never ships because it can’t decide what it is.
Phase two · Filters
Personas as rejection filters.
Most personas are aspirational and decorative — the “young creative professional, loves coffee” type. I built four for PaintRack, but only two function as filters. They don’t tell me what to build. They tell me what to reject.
Marcus
41 · Senior engineer · 200+ paints
Saturday afternoon set aside to finish a King Tiger. Filters every interaction at the bench: gloves on, model half-painted.
The test
Would he tolerate this friction right now? The Marcus filter killed an entire collection-sharing flow that read well on paper but failed the bench test.
Yuki
28 · Professional UX designer
Will delete the app on sight if the UI feels generic. Filters every visual decision against the first-launch test.
The test
Would she accept this typography, or delete on sight? The Yuki filter killed a draft of the catalogue list that was functional and visually forgettable.
Developed with Claude in a structured session — described archetypes, Claude proposed candidates from research-shaped patterns, I pushed back on composites, refined until each had a sharp edge. The decorative third and fourth personas don’t appear in the build. Only the filters made the cut.
Phase three · Contract
Design spec as build contract.
Order of work
- Tokens
- Components
- Screens
- Patterns
The PaintRack design spec runs to roughly forty pages — tokens, type scale, spacing, components, screen-by-screen specs, animation timing, accessibility notes, platform adaptations. In a typical agency engagement, this is six weeks for a small team. I produced it in three working sessions, at quality.
I worked structurally — tokens first, then components, then screens, then patterns. Claude operated as a senior design-system peer at each layer: proposing structures, surfacing edge cases, asking “have you thought about what happens at 200% font scale?”
The Figma MCP plus Claude Code’s design-system skills changed the build of it. Instead of laying out every component, variant, and token by hand, Claude built the system directly in Figma — creating components, applying variables, wiring auto-layout — under my direction. The work I was uniquely positioned to do (every aesthetic decision, what good looks like) stayed mine.
The output is a document an engineer can build from — readable by both humans and language models, because the build phase would lean on the latter.
Phase four · The build contract
Engineering the Claude Code prompt.
CLAUDE.md · ~400 lines
# PaintRack ## StackReact Native · Expo · TypeScriptZustand · expo-sqlite ## Tokensref: /design/tokens.json ## Build order01 catalogue → 02 inventory → 03 lists → 04 assistant ## Must not— fabricate confidence— skip session-start protocol— invent components outside the spec // executable artefact. read first, every session.This is the phase without precedent in traditional design. I wrote a CLAUDE.md file — about 400 lines — that serves as the build contract for Claude Code.
Tech stack, design tokens, component specs, build order, things Claude Code must not do, session-start protocol. This document isn’t documentation. It’s an executable artefact. When I open Claude Code, that file is the first thing it reads. The quality of every component, every screen, every interaction is downstream of how rigorously it was written.
Writing it forced a different kind of design thinking — anticipating ambiguities that don’t matter to a human collaborator but matter intensely to a language model: what the file structure is, which screens build first, what the agent does when it hits a missing asset, how it reports uncertainty rather than fabricates confidence.
This is design work, even though it produces no visible artefact. It’s the design of an AI’s working environment — which is, increasingly, where senior designers’ leverage lives.
Phase five · Ownership
What AI handed off vs. what I owned.
Status
TestFlight-equivalent. Real, not a prototype. Catalogue, My Paints, Shopping List, AI Assistant — all working end-to-end.
Honest about the split. AI didn’t replace me. It compressed the parts of the work I could direct but not execute alone — scaffolding the codebase, wiring components, implementing screens from the spec, hooking the SQLite layer to the inventory state — and freed me to spend my time on the parts only I could do.
The split that matters: AI handled execution where my intent was unambiguous. I owned every decision where intent had to be formed. That’s the model — not “AI builds the app,” not “I built it alone.” A collaboration with a defensible division of labour.
AI handled
Execution, where intent was unambiguous.
I owned
Every decision where intent had to be formed.
- Scaffolded the codebaseEvery visual decision
- Wired components from specInteraction model & feel
- Implemented screensWhat Marcus & Yuki would forgive
- Hooked SQLite to inventoryAesthetic direction, end-to-end
The build · Output
Selected screens.
The key surfaces at a glance.
Navigation flow — login through brand, category, and paint detail. The drill-down spine the rest of the app sits on.
Reflections
The biggest takeaway is uncomfortable for anyone hoping AI is a shortcut. The PaintRack strategy document, the spec, the CLAUDE.md — they aren’t scaffolding around the AI work. They are the AI work. The model is only as senior as the brief you give it, and there is no version of fluent AI use that lets a designer skip the thinking. What it lets you skip is the unglamorous execution that used to consume most of the engagement.
The second is that design documents written for both humans and language models are a new kind of deliverable. The spec, the CLAUDE.md, the in-context prompts that shape a Claude Code session — these are design artefacts, with their own conventions, failure modes, and quality bar. Worth learning to write well; we’re going to be writing them for a long time.
The third is that AI doesn’t replace senior judgement. It dramatically extends what senior judgement can produce alone. The PaintRack build is the kind of project that, five years ago, I’d have either shelved or paid a small team to deliver. Now I can take the same idea from problem framing through to a working app, on my own, in evenings and weekends, at a quality bar I’m willing to put my name on. The bottleneck for a designer building real software is no longer technical. It’s how clearly you can specify what you want.
The rigour you bring to the AI work is the ceiling on the output. Vague in, vague out.
— What I learned
More case studies
