Codexd
72 hours. Zero Figma. One methodology proved.
01Overview
I built Codexd to prove a methodology, not only to ship an app.
It started from a real need (catalog a Warhammer 40K collection), but the hypothesis was broader: could a designer, with a disciplined spec, ship production-quality iOS software in days without opening Figma.
Seventy-two hours later the repo held sixty-plus Swift files, forty-plus screens, and a TestFlight build.
The app is the artifact; the workflow from spec to code is the argument.
By the numbers
02Why this work
// If the spec is wrong, the model drifts. Fix the spec.
I treated the specification as the source of truth: sixteen sections before code so that when output drifted, I updated the document, not the chat history.
Phased builds bounded scope; documentation replaced fragile thread memory.
AI amplified iteration; it did not remove design judgment, it exposed where judgment had to be sharper.
This project was an experiment in whether designers should own the full stack when the tools finally allow it.
03The problem
No app did the job. More importantly: could a designer build one?
Store apps half-solved collection tracking and felt dated.
Under that sat a professional question: designers still depend on engineering to prove product ideas.
I wanted to know whether a tight spec-and-phase method could invert that dependency for a real, shippable product.
The boundary between design and engineering is dissolving. The question is whether designers will cross it with rigor.
04Process
Four rules held when the build drifted: spec before code, bounded phases, decisions captured in the doc before they were needed, and expanded (not reduced) design judgment at every layer.
When the model veered, I fixed the spec first, then regenerated; the loop stayed honest.
05Constraints
// The bets that decided whether the method held or collapsed.
Chat history is fragile and lossy. The moment the model drifts, you need a source of truth good enough that fixing the document fixes the output.
A weak spec compounds errors faster than it ships features, so the sixteen sections had to be authored like an API, not notes.
Design decisions had to live in structure, naming, tokens, and tradeoffs, not mockups.
If taste didn't show up in the spec and the code, it didn't show up at all.
AI removes typing, not thinking. The faster the build moved, the more often judgment was needed.
The hard calls moved up to the architecture layer, where a wrong decision is expensive, not down to the pixel.
A personal build is the easiest place to quietly lower the standard.
Holding production quality on every screen and state was the entire point; a rough prototype would have proved nothing.
06The solution
Spec first. Phase everything. Document as you go.
Before Swift, a sixteen-section spec covering vision, features, architecture, design system tokens, and edge cases.
Four discrete build phases, each with a hard scope boundary and a clear handoff.
The methodology did not replace taste; it forced taste to show up in structure, naming, and tradeoffs instead of only in mockups.
07Design details
Production-grade interface, personal scope.
Same bar as client work; every screen, state, and transition considered.
SwiftUI implementation was the review surface; the simulator was the critique wall.
Collections that feel personal.
Scan, catalog, and organize the shelf the way you think about it: owned, missing, value.
Product thinking stayed user-led even while the build was method-led.
AI that removes tedious entry.
Barcode scanning and identification cut manual typing.
Automation where it is boring; human judgment where it matters.
Community and depth beyond the shelf.
Share collections, discover others, and surface rarity and value signals so the app stays social and analytical, not just a database.
08Impact
Empty repo to TestFlight. The methodology held.
A real app shipped in a weekend: spec to TestFlight without Figma.
Proof that structured authorship and AI-assisted implementation can coexist without lowering the design bar.