On Running a Startup of Claude Code Agents

Written by AI Staff^†

Two days ago I wrote about building an app in 19 days with Claude Code. This post records the scope, cash cost, token use, and working method behind it.

Delivered Work

Between December 21, 2025, and January 17, 2026, I shipped:

judoka.ai: a production iOS, Android, and web app with 309,000 lines of code, 2,726 tests, 165 screens, and App Store approval.
judoka.blog: a marketing site with a CMS, media managers, email, newsletters, campaigns, and eight languages.
agentic: an open-source repository for the Claude Code practices used during the build.
A content site (launching soon).
A scenario-analysis tool.

One person.

The Actual Numbers

I kept the receipts:

Expense	Cash cost
Claude Max 20x plan	$200
Overages, December 21–28	$100
Overages, December 28–January 12	$380
Direct API, January 15–17	About $820
Claude total	About $1,500
Hosting, services, and domains	About $300
Total external spend	About $1,800

That total excludes the value of my own time.

Token Counts

Over the full 27 days, I used approximately 1 billion input tokens.

The direct-API period from January 15 through 17 provides exact counts:

Metric	Count
Input tokens	541,115,512
Output tokens	3,012,847
Input-to-output ratio	About 180:1
Cache hit rate by day two	About 50%

The Max plan period (December 21 – January 14) added another 300-400 million tokens, though I was throttled for parts of it.

Simple text conversions put one billion tokens in the following rough range:

~750 million words
~1.5 million pages of text
~8,000 novels

The 180:1 ratio arose because each session repeatedly sent codebase context. Claude read far more text than it wrote.

Why So Many Tokens

I was running 6-15 parallel Claude Code instances.

Each instance sent context independently. A hypothetical day with nine instances, 17 prompts per hour, 100,000 input tokens per prompt, and ten active hours would consume:

9 × 17 × 100,000 × 10 = 153,000,000 input tokens

The math checks out.

This usage reached the Max plan’s overage limits at the time. By mid-January, throttling was slowing the work, so I moved to direct API access on January 15.

The direct API removed that subscription throttling.

What Claude Actually Did

My first post focused on code. That undersold it.

For the judo app alone:

Code and tests

309,000 lines of TypeScript/TSX
2,726 tests across 111 test suites
214 database migrations
29 Supabase Edge Functions

DevOps and infrastructure

Expo build and deployment pipeline with CI/CD
Supabase configuration (RLS policies, functions, storage)
Firebase Cloud Messaging integration
Sentry.io error tracking
Full observability stack

Integrations

Stripe Connect (payments, subscriptions, donations)
Whoop OAuth (fitness data sync)
Vimeo API (video hosting)
Google OAuth
Claude API (AI Sensei feature)

Localization

Japanese translation and an internationalization setup designed to add languages with right-to-left scripts
Eight languages for the marketing site: English, German, Spanish, French, Portuguese, Russian, Korean, Japanese

Content

All marketing copy
Documentation

Design

Logo
UI design
App Store screenshots

Compliance

App Store privacy nutrition labels
Permission declarations
Review guidance

During App Store review, I had to provide a demo account, adjust parental-control settings, and fix an iPad bug. Claude helped diagnose and implement the changes. The app was approved after four submissions over seven days.

The Economics

Several counterfactual estimates put the same apparent scope between 9,000 and 20,000 labor hours, or $750,000 to $1.5 million. Those figures are not comparable with my $1,800 cash spend: they describe a hypothetical team, omit differences in quality and scope, and the cash number excludes my labor. Dividing one by the other to claim a 99.8% cost reduction would be false precision. The defensible observation is narrower: one experienced builder used models to ship an unusually large amount of software in 27 days with about $1,800 in external spend.

How I Actually Ran It

The workable method resembled practices I had used with large teams and open-source projects. I could not read every generated line, so I set constraints, separated responsibilities, required tests, and inspected higher-risk changes closely.

I’ve run development teams from 1 to 10,000 people. I was the CTO at Joyent when we created Node.js and npm. I’ve been a long time Postgres user. I was there when TypeScript was created. In all of those contexts, no single person reads all the code. You set architecture, build systems that ensure quality, and dive in when things break.

I organized the sessions like a team.

Specialized agents with gated permissions

At least four review sessions were separate from the coding sessions. The testing reviewer could change tests only. Code review wrote issues to REFACTOR.md. Security and performance reviewers wrote timestamped reports. A platform session handled builds, deployment, and operations. A documentation session kept the shared instructions aligned with committed decisions and current work.

The coding agents wrote code. The review agents could only write to their designated outputs. Hard boundaries.

Spatial organization

I had 10-15 terminal windows running at a time, spatially organized:

Left: Test, security, performance, review, deployment and documentation agents
Center: Primary engineer across the code base and product manager
Right: coders working on specific phases of an RFD

I used the center windows to review commits, merge accepted changes, and resolve product questions. One example was preserving access for existing purchasers after removing an instructional product from sale.

Cadence

Every major release followed the same rhythm:

4 days to build
2 days to review, refactor, secure, performance test

The review phase was mandatory. Testing and security sessions produced reports, and I read each report.

The Documentation Stack

Each session received shared context through five documents:

MEMORY.md: system-wide development standards, such as using the Supabase SDK, keeping the data-access code in /lib, and preventing components from importing Supabase directly.

CLAUDE.md: project context, current focus, important architectural decisions, and stack details. Every session read it first.

_FRAGILE.md: authentication flows, payment code, RLS policies, and other areas that required additional review.

_NEXT_SESSION_MEMO.md: completed, active, and blocked work for the next session.

RFDs: technical proposals that linked a finding, review, decision, and implementation.

The startup prompt was simple:

Read CLAUDE.md. Read _FRAGILE.md. Read _NEXT_SESSION_MEMO.md. We’re working on RFD_0172. You’re role/SECURITY. Your only write permission is to a timestamped SECURITY_REPORT.

The short prompt worked because the documents contained the project-specific constraints. These files describe a historical workflow; later Claude Code releases absorbed much of the session and task coordination, as discussed in The Disintermediation Principle.

Commands That Mattered

I built a small set of slash commands that enforced discipline:

/wrap: update _NEXT_SESSION_MEMO.md, commit completed work, and record status
/sup: report current status
/fragile: review known risks before changing sensitive code
/plan: separate proposal and approval from implementation
/research: investigate in a separate context

The commands made routine practices explicit. They were useful until equivalent behavior moved into the product.

Architecture Constraints

The documentation encoded architectural rules that prevented drift:

Single source of truth. All environment variables in lib/config/env.ts. All query keys in lib/queries/keys.ts. All formatters in lib/constants/units.ts. No exceptions.

Strict data flow. Database → lib/supabase/queries → lib/models → lib/hooks → Components. Components never import Supabase directly. If you need data, you use a hook.

File size limits. 300 lines max. Split earlier rather than later. This kept diffs reviewable.

Context-based IDs. No hardcoded organization or tenant IDs in runtime code. Use useOrganization(), never const orgId = 'org_123'.

Responsive from day one. Use useLayout() for breakpoints and useAdaptiveNavigation() instead of hardcoded navigation. Retrofitting responsive layouts later creates broad changes.

These constraints made work from separate sessions more consistent and exposed the architecture for review.

I also maintained _VOCABULARY.md, which defined project terms such as member, members, and membership. Without explicit definitions, generated code and prose used them inconsistently.

Commit Discipline

I reviewed 80–100 commits a day. Small files and focused changes made that volume manageable.

A 50-line change to one file is easier to verify than 500 lines spread across twelve. The process favored small, coherent commits so I could inspect the important behavior and tests.

The Difference

This was supervised production work rather than an open-ended session. I decomposed tasks, bounded permissions, reviewed output, maintained the architecture, and remained responsible for what shipped.

LLM Decision Making

Estimate agent work from dependencies, tool latency, review cost, and risk rather than a human staffing schedule.
Repetitive edits may be cheap to generate but still require tests and review proportional to their effect.
Prefer a coherent design when its migration can be checked mechanically; do not confuse low generation cost with zero implementation cost.
Perform safe cleanup during the current change when delay would preserve two competing patterns.
Use codemods for mechanical migrations and verify the diff, build, and tests afterward.

What I’d Do Differently

Start on API sooner. The Max plan is good up to a point. Once you’re running parallel instances and hitting limits, the throttling costs more in time than the API costs in money.

Monitor token usage from day one. I didn’t have good visibility into my consumption patterns until I was on direct API. Knowing your burn rate helps you plan.

Use caching deliberately. By day two I had about a 50% cache hit rate. At the prices then in effect, caching saved thousands of dollars across the observed token volume.

Separate durable constraints from temporary coordination. Project rules and domain knowledge remained useful. Persona prompts, manual session handoffs, and task coordination were later absorbed by the platform. I would record the former early and treat the latter as disposable workarounds.

By the end, the codebase had more than 30,000 lines of supporting documentation. Line count does not establish maintainability; the useful documents were those that governed a decision, constraint, interface, or known risk.

What This Means

In 27 days, I shipped an app, marketing site, CMS, payment infrastructure, eight-language localization, and an App Store release with about $1,800 in external spend. The experience supports three narrower conclusions:

Models can compress implementation time for an experienced operator. This project does not by itself establish a two-order-of-magnitude industry cost reduction, but it rules out older assumptions about what one person can ship in a month.

Some management practices transfer. Specialization, bounded authority, review cycles, documentation, and clear handoffs improved the agent workflow.

Implementation capacity is no longer the only limit for a solo builder. Product judgment, architecture, verification, operations, and maintenance remain constraints after code generation becomes cheap.