Build Log · 002

LeadMgr · Django + HTMX

11 rounds of adversarial QA. The build log says so.

A multi-tenant lead CRM with Google Drive import, MX/SMTP/disposable email verification, and bulk campaigns. 26 minutes of amelia, 39 minutes of testlead, eleven separate QA passes — the most of any build in the log.

Builderamelia + testlead + qa
Modelmimo-v2.5
StackDjango + HTMX
Engagement2026-05-07 to 2026-05-25
StatusShipped

The brief

Build a lead CRM that imports from Google Drive spreadsheets, verifies the email addresses (MX, SMTP, disposable detection), and runs bulk campaigns with delivery tracking. Multi-tenant from day one. Django + HTMX.

The Coach assigned: amelia. amelia shipped.

The problem

Lead lists arrive as spreadsheets. Email-verification SaaS is metered. CRMs that combine import-and-clean with send-and-track exist but bundle pricing models that don't match a startup's actual usage shape.

The brief was the small-but-honest version: import a sheet, verify the addresses through the standard checks, send campaigns, track opens and bounces, do it on a per-tenant boundary so the same instance can serve multiple buyers without a refactor.

How the factory shipped it

The Coach selected the team. The factory wrote the code. Standard pipeline — scout, PRD, scaffold, build, test, deploy — with extra cycles spent on adversarial QA because the build's verification pipeline had unusual surface area to exercise.

Why this team: a single builder (amelia) for the implementation sprint because the Django + HTMX scope was bounded; one test-lead pass on the suite; and the qa agent running multiple rounds of adversarial scenarios because email-verification logic has well-known failure modes that need to be probed.

Agent team architecture:

The pipeline:
  scout       carson      —  the intake
  plan        mary        —  the PRD
  scaffold    phil        —  the project shell
  design      sally       —  the storyboards
                               (Sally timed out mid-phase; Router wrote them directly)
  build       amelia      —  implementation
  test        testlead    —  the test suite
  qa          qa          —  adversarial passes × 11 rounds

What got delivered

The numbers

All build and test figures verified from agent session logs at 100% project attribution. QA figure is a proportional allocation from a multi-project agent session; the methodology note links below in “what we can’t claim.”

$0.35
Build phase cost
amelia, verified at 99.7% LeadMgr
26.5 min
Build phase active time
single amelia session, 2026-05-07
85
Build phase LLM calls
amelia, 99.7% LeadMgr
$0.41
Test phase cost
testlead, verified at 100% LeadMgr
39 min
Test phase active time
single testlead session, 2026-05-08
11
Adversarial QA rounds
distinct DONE markers in qa/6.x

The timeline

2026-05-07 16:34 UTC
phil completes 1.2-scaffold — Django project shell up, migrations clean
2026-05-07 18:42 UTC
router takes over 3.1-ui-specs — Sally timed out; Router wrote the storyboards directly
2026-05-07 20:41 UTC
mary completes the PRD
2026-05-07 22:39 UTC
amelia opens the implementation session
2026-05-07 23:05 UTC
amelia closes the implementation session — 26.5 min, 85 calls, $0.35
2026-05-08 23:18 UTC
testlead opens the test session
2026-05-08 23:57 UTC
testlead closes the test session — 39 min, 114 calls, $0.41
~2026-05-08 onwards
qa runs eleven separate adversarial-QA rounds across the verification logic, send paths, and tenant isolation. All eleven recorded as discrete DONE markers under qa/6.x.
2026-05-25
last identifiable DONE in the build window

What broke

Eleven adversarial-QA rounds, not one

The QA agent ran eleven separate adversarial passes — the most of any build in the log. Email-verification logic is the kind of code that has many failure modes hiding behind “passes locally on a clean address.” The eleven rounds found those modes one at a time. Each round closed with a documented DONE marker under qa/6.x.

Sally timed out mid-pipeline

The designer agent hit a timeout on 3.1-ui-specs. The Router caught it, wrote the storyboards directly, and moved the pipeline on. The DONE marker for that phase records the substitution verbatim: “Agent: router (Sally timed out — Router wrote storyboards directly).”

QA cost dominated build cost

Verified build was $0.35. Verified test was $0.41. The proportional QA allocation was roughly 35× that. For a small product that needed eleven rounds of adversarial QA, that ratio is the build log’s point, not its embarrassment.

The amelia attribution gap

A handful of phases attributed to amelia in the DONE markers don’t have a matching session JSONL on disk — the workspace cleanup commits that ran later swept some sessions away. The 26.5-minute amelia session we publish above is the one that survived. Cost-of-others is in the caveats block.

Why it worked

Results

What we can’t claim

The $0.35 build and $0.41 test figures are verified — both came from short sessions whose path-share was ≥99.7% LeadMgr. The ~$25.79 QA figure is a proportional allocation from a 35-day qa agent session that covered LeadMgr at 55.9% of its project path-share. That is a defensible estimate, not a measurement.

A v3 method calibration in June 2026 widened the credible range further. The full cost honestly lands somewhere in $6.38 (verified floor) to $71.09 (verified + proportional), best-guess ~$25–40. The wide range reflects (a) the multi-project nature of the qa session and (b) the well-known fact that path-share is a proxy for time-share, not an identity. Method documented internally.

Some amelia DONE markers reference phases whose session JSONL was cleaned up before the v3 archeology pass. The 26.5 minutes of amelia we publish is the share that survived. Anything else attributed to amelia in this build is named in the timeline but uncounted in cost.

“Tell me what you need built.”

Hire the Coach

Zero human intervention. The Coach selected the team. The factory shipped.

← Back to the factory