Method

Spec-First Solo Build

How I take a product to launch by setting the bar and directing AI — without writing the code myself

The Spec-First Solo Build method, condensed

This page distills the working rules I've actually followed into one method. It's not marketing copy — it's the procedure I repeat on every project. The templates below are public skeletons. Per-project real excerpts live in each case study under "Directing AI."

(01)

Framework: 7 steps from zero to launch

Fig. ai-workflow-01

Plan to ship — the direct · check · correct loop

01IdeaDefine the problem

02Plan & barScreens, structure, acceptance criteria in writing

03Direct the AIGoal, criteria, constraints — one step at a time

04Run & checkPlay, build and read logs against the bar

05ShipSecurity & data check, then stores and web

Off the bar → point at the cause, re-direct · repeat

I don't write the code myself: I set the bar, direct the AI step by step, run it myself and correct. Steps 3↔4 repeat until the bar is met.

01
Set the rules and design in docs first
Since I don't read the code directly, the first line of defense for quality is a rules document. Per project I pin my way of working, the don'ts, and the verification bar in a rules document, then have each session read it and sync with "tell me the current stage."
02
Pull all the design/UI and data first, then build
Doing both at once gets tangled, so I lock screens and data first. (e.g., export all screens in a design tool, then wire them in code.)
03
Instruct in small pieces and verify by running it myself
Not "it's done" — I run it on a phone/simulator and confirm **with my own eyes**.
04
Give the bar and benchmarks in words, not scores
I specify quality by reference (big-company apps) and tone, and delegate the implementation.
05
Catch what's wrong and change direction
I distrust plausible success ("this isn't hardcoded, right?") and, when stuck, pivot immediately to what works (no fakes, pragmatic pivots).
06
Don't trust AI's self-report — verify with evidence
I re-confirm with the actual code, artifacts, or different inputs, not "memory."
07
Keep context in handover docs and run multiple AIs like a team
I document context so it survives account/context changes, and for multi-session work I appoint one session as PM.

Spec-First Solo Build — write the rules and the bar first, then direct AI to build, check, and correct until it ships.

Steps 3–6 aren't one-and-done — I loop instruct → check → correct.

(02)

Principles

01
Don't guess
If one fix fails, search official docs/similar cases before the second attempt.
02
Show before building
New screens/structures are reviewed as mockups or designs first, then built.
03
State the impact before changing
Explain side effects and knock-on issues first; change only after approval.
04
Verify the value flows end to end
Adding a field/parameter means fixing every call site, not just the definition, and re-reading the generated code before submitting.
05
For "can't be wrong" areas, write the bar down
Where mistakes are fatal (security, payroll), the design doc comes before code.
06
Turn failure into a principle
From one loss or incident, extract one rule that prevents a repeat. (The "approve before changing" rule came from an early trading-bot failure.)
07
Keep docs and code in sync
Every release, I check the figures in the docs against the actual code. AI-written docs drift easily, so I make the cross-check a habit.

(03)

Prompt Templates (skeletons)

I share only the skeletons of the instructions I reuse. The detailed conditions, ordering, and acceptance criteria that actually made them work are shared in interviews/collaboration. Short per-project excerpts (1–2 sentences) live in each project's case study under "Directing AI."

A. Idea evaluation — no arbitrary scores; grounded in real cases

Redefine the problem → search similar cases → compare success/failure patterns
→ evidence-based scorecard → derive ideas → summary (top + risks + next action)
[per-step criteria, counts, and pass/fail rules are kept private]

B. Feature instruction

[Goal] …   [Bar] behaves like this / not this   [Constraints] stack & policy (checked in docs)   [Check] what I'll inspect

C. Bug-fix instruction

[Symptom] …   [First] cause first — search & hypothesis   [Before fixing] explain impact → change after approval

(04)

How I Catch Errors

01
State the symptom as fact
I tell AI what happened, when, and on which screen, reproducibly.
02
Cause first, no guessing
I search official docs/similar cases and form a cause hypothesis.
03
If the first fix misses, stop
I search again before the second attempt — I don't repeat the same guess.
04
Verify the value flows end to end
After fixing, I re-read every call site and the generated code.
05
Leave a rule that prevents a repeat
I record it as a working principle or design bar.

Real debugging cases (symptom → instruction → failure → fix) live in each project's "How I Fixed It".

(05)

Mistakes → Lessons

Mistake
Over-trusting a trading bot → a loss
✓ Lesson
explain impact and get approval before changing (still applied on every project).
Mistake
AttenNFC: AI-generated code below the bar
(only 5 of 9 payroll variables, API mismatch, hardcoded GPS).
✓ Lesson
verify AI output against the bar and, when it diverges, instruct a rewrite. After the rewrite I confirmed `flutter analyze` reported zero issues.
Mistake
MECHOOSE: early screen structure packed into one file
✓ Lesson
set the separation bar at the start — it makes later changes cheaper.

(06)

The work in numbers (approximate)

149 claude.ai conversations · ~9,002 user instructions (Feb–Oct 2026, ~8.5 months) — total activity, including personal and non-portfolio chats.
Five products reached a launch/deploy stage (THE HOUSE, MECHOOSE, Momento, Money Navigation, MemoHub); two running live (MECHOOSE, MemoHub).
Most instructions in a single conversation: THE HOUSE, 696.

Figures are record-based approximations (per-project classification of chats is a title/keyword heuristic, so estimated).

(07) Honest

Honest Review

If a developer had built it — strong · on par · next step

StrongOn parNext step (in progress)

THE HOUSE
Strong3On par4Next step5
↗ Testing & automation — no automated tests or CI yet
Plan → Tests + CI for purchases and saves, module split, private Git, server-side purchase checks before public launch
MECHOOSE
Strong3On par4Next step4
↗ Testing & automation — no tests, CI, lint, or type checks yet
Plan → Tests + CI on payments first, split the backend by domain, move orders and payments to proper tables, add error alerting
Momento
Strong3On par4Next step5
↗ Testing & automation — only the matching engine has tests
Plan → Pin the live schema in the repo, add core-flow tests and CI, server-side purchase checks, Android parity
AttenNFC
Strong2On par3Next step4
↗ Feature completeness — implementation ~10–15% of the design
Plan → Finish one verified check-in round trip end to end, then tests/CI, translations, and labels as screens are built
AI Video Streaming Platform
Strong4On par3Next step3
↗ Testing & version control — no tests, no git
Plan → Private Git and payment tests first, then CI, monitoring, backups, and rollback