I spent Christmas break building an app with Claude Code. Not toy code. Not a demo. A production iOS/Android/web application that Apple approved for the App Store three weeks after I started.

The experience was amazing and I’ve been thinking about how what actually happened.

The Setup

I train at a dojo in Santa Clara and have been talking to the owner, Shintaro Nakano, about this application idea for the last couple of years, and had always said it would take a couple years to do it to the scope that we discussed. The dojo has the standard operational chaos—paper waivers, group texts about who’s coming to practice, parents asking if their kid actually showed up. I wanted to build the dojo app I wished existed.

I’ve spent my career in infrastructure and software. I know how to build systems, code, run teams ranging from 3 to 30,000. But I hadn’t shipped a React Native app in a long time (which is when it came out), didn’t know Supabase, wasn’t exposed to Expo.dev before and hadn’t touched production Claude APIs.

I started on December 21st. By December 27th (six days) we had a production app with authentication, attendance tracking, AI coaching, and real users. By January 4th, we had a multi-tenant platform with a dojo directory, Stripe payments, and a video marketplace. By January 15th, Apple approved us for the App Store.

The app is live at judoka.ai. There’s a marketing site at judoka.blog. Real people use it to check into judo practice.

Nineteen days of active development. Around 309,000 lines of code. 2,726 tests. 214 database migrations. The works.

The Arithmetic

Here’s where it gets eye opening.

Using standard estimation methods—COCOMO, feature decomposition, complexity analysis—this codebase represents roughly 9,500-12,000 person-hours of traditional development effort. That’s 5-6 years of solo work, or 12-15 months with a five-person team.

I did it in 19 days.

The math suggests a 71x acceleration factor. On peak days, I was committing changes equivalent to weeks of traditional development every few hours.

Phase Days Commits Traditional Equivalent Acceleration

v1.0 Foundation7533420 dev-days60xv2.0 Platform8652645 dev-days81xv2.4 Global Ready4303278 dev-days69x

The acceleration was highest during v2.0, when we were building on established patterns. Claude doesn’t just write code faster—it creates a compounding effect where each solved problem becomes a template for the next.

What I Learned

Halfway through, I started extracting the patterns that worked into a reusable framework. The things Claude (specically 2.1.x needed to know because a lot that I found online seemed to already be done by the app). The constraints that prevented chaos. The documentation structure that maintained coherence across sessions.

I’ve published this as agentic—a minimal Claude Code setup for React Native and Supabase projects. It’s the distillation of what I learned building Judoka.

The core insight: Claude Code needs guardrails, not instructions. Heavy prompts are overhead. What works is:

Constraints that prevent drift:

• Files under 300 lines, always (larger is okay if being a monolith makes sense, the largest file is ~1200 lines)
• Data layer only in /lib—components never touch the database directly
• Query key factories, not string literals
• No hardcoded IDs in runtime code

Documentation that grows with the project:

• CLAUDE.md for project context
• _FRAGILE.md for danger zones (auth flows, payment code, RLS policies)
• _NEXT_SESSION_MEMO.md for continuity between sessions

Session hygiene:

• /wrap at the end of each session—commit and document
• /fragile before touching anything dangerous
• /plan for anything non-trivial—get approval before implementing

The framework is minimal by design. Claude Code 2.x internalized most of what used to require elaborate prompting. Short context plus constraints beats long role definitions.

The Uncomfortable Parts

Let me be honest about what this surfaced.

The volume problem. I generated more code in three weeks than I could realistically review in three weeks. I developed heuristics for when to trust and when to verify. Tests helped. TypeScript helped. But there’s an irreducible gap between generation speed and comprehension speed.

The ownership question. When Claude writes 70% of the implementation, who understands it? I designed the architecture. I specified the features. But if you asked me to trace a specific piece of state through three hooks and two context providers, I’d have to read it like I was reading someone else’s code. Because I am.

The pattern lock-in. Claude learns your codebase patterns and applies them consistently. This is mostly good—it’s how you get coherent large systems. But it also means early architectural decisions propagate faster than you can reconsider them. The feedback loop between “this might be wrong” and “this is now everywhere” compresses from months to hours.

The debugging shift. Traditional debugging is bottom-up: see a symptom, trace to a cause, fix it. Claude-assisted debugging inverts this. You describe the symptom, Claude proposes causes, you validate. It’s faster but requires a different skill—knowing when Claude’s explanation is plausible versus when it’s confidently wrong.

What I Think This Means

If an individual developer can build production software 70x faster, several things follow:

The economics of small teams change radically. A solo founder with Claude can ship what used to require a seed round and six engineers. The capital efficiency is significant.

Quality becomes the bottleneck. When generation is cheap, verification becomes expensive. The gap between “code that compiles” and “code that’s correct” widens.

Architectural skill matters more, not less. Claude is excellent at implementing patterns. It’s less reliable at knowing which patterns are appropriate. The judgment layer—what to build, how to structure it, what invariants matter—remains stubbornly human.

Maintenance is the open question. I can generate code faster than I can understand it. Can I maintain it? Six months from now, when something breaks at 2am, will I be able to trace through code I never fully internalized?

The Contract I’m Making With Myself

I’m agreeing to treat AI-assisted development as a power tool, not an autopilot. Power tools amplify both skill and error. They demand more attention, not less.

I’m committing to understanding the architecture even when I didn’t write the implementation. If I can’t explain why a piece of code exists, I shouldn’t ship it.

I’m accepting that this changes the economics of what I can build, while recognizing that “can build” and “should build” remain separate questions.

Links

• The app: judoka.ai
• Marketing site: judoka.blog
• The framework: github.com/jasonhoffman/agentic