The live demo on this site went from a written spec to a deployed system in 29 days: spec dated May 29, 2026, live on Fly.io on June 27, 74 commits in between. One engineer, plus coding agents. Infrastructure runs about $20 a month. An agency would quote that shape of project as a team and a quarter, and by the agency's method the quote is honest. This post is the engineering explanation of the gap.
The mechanism is simple to state. Coding agents removed typing speed as the constraint on shipping software. The constraint that remains is how fast one person can read a diff, make the architecture call it implies, and answer for it in production. My whole setup, and the four-week sprint that falls out of it, is engineered around that one constraint: review bandwidth.
ByteByteGo recently profiled an ex-Meta L8's agentic engineering setup. This is mine, with production receipts attached.
Review bandwidth is the whole game
Agents generate working diffs faster than I can read them. That inverts the old economics: code got cheap and judgment did not, and every diff that merges carries my name into the next incident. On the systems I run for clients, the person who accepts a change answers for the outage it causes, so a diff I merged without understanding is a liability no matter who typed it.
Delivery throughput therefore equals review throughput, and two moves raise it. First, shrink the judgment needed per diff: write the spec so agents cannot wander, keep file lanes disjoint so merges stay trivial, load prior corrections so old mistakes stay fixed, and have reviewer agents filter the obvious problems before a human looks. Second, move whole classes of checks to machines: quality thresholds run as CI merge gates, so a retrieval regression blocks itself at the PR without waiting for my attention. The four-week sprint is those two moves put on a calendar.
The spec buys the parallelism
No production code until the spec settles. Every non-trivial spec goes through 4 to 5 review rounds, and the doc-intel spec came out of that process as 14 implementation chunks across 5 lanes: ingest, index, retrieve, observe, eval. Each lane owns a disjoint set of files, so work in one lane cannot collide with work in another.
The eval harness goes in alongside the spec, before the pipeline it will judge exists. Three scorers run on every PR with the delta posted as a comment (faithfulness 0.97, citation correctness 0.95, recall@k 0.93 on the demo's current backend), and a regression removes the merge button. I wrote up the mechanics in evals as CI. Setting this up first feels slow and is the opposite: every hour spent on the spec and the gates multiplies the parallelism that is safe once the build starts. A vague spec serializes everything through my head. A chunked spec with lanes lets several agents build at once while I stay off the critical path.
Parallel lanes, one integrator
This is where the calendar changes shape. Several Claude Code agents run at once, each confined to its lane. Before an agent touches code, it loads the relevant entries from a library of roughly 85 versioned SKILL.md files, domain expertise and past corrections encoded as text the agent reads before working. I described that library in how AI agents remember. The effect on review is direct: a mistake I corrected in March does not come back in June, so my attention goes to new problems instead of old ones.
Each chunk then passes a two-stage agent review before I see it: one pass for spec compliance, one for code quality, with the implementer fixing findings between passes. What reaches me is a candidate that already survived two readers. My read is the final gate, and it is the only stage in the loop that does not scale, which is exactly why everything upstream of it exists.
A build day looks like this: merge the reviewed chunks that pass, then settle the cross-lane questions agents cannot decide on their own, which means schema shapes, API contracts, and the tradeoffs the spec left open. Where reality disagrees with the spec, the spec gets amended in writing. The calendar looks like a tech lead's, for a team that does not sleep. On the doc-intel demo this cadence produced 74 commits in 29 days without a second human.
Why a flat fee survives this
The commercial terms, exactly as the operator brief states them: $20k per 4-week sprint, flat, no hourly billing, 50% on signature and 50% on Week-4 handover.
The paid sprint front-loads discovery on purpose. Week 1 is 6 to 10 customer calls, recorded with consent, so the spec traces to what customers actually said instead of what the founder remembers them saying. Week 2 writes one ADR per load-bearing decision. Week 3 produces the chunked implementation spec through those 4 to 5 review rounds. Week 4 ships the first chunks as a working MVP, built with the parallel-lane method above. And if the week-1 calls invalidate the whole thesis, the engagement has a mutual exit that Friday at 25% of the fee, with the client keeping the research corpus.
A flat fee dies in two ways: scope drifts, or quality collapses late and the fix eats the margin. The chunked spec handles drift, because the deliverable is enumerated in writing and both sides can count what shipped. The eval gates handle late collapse, because a regression cannot merge quietly mid-build and surface after handover; it blocks at the PR the day it is written. And the delivered system is cheap to keep alive: the demo runs on about $20 a month of Fly.io machines, so proving the work still runs long after the sprint costs less than the kickoff call's coffee.
What does not compress
The honest half of the four-week claim is the list of things agents did not speed up.
- Discovery. Understanding which problem is worth four weeks takes conversations with the people who have it, and those happen at calendar speed.
- Access provisioning. Credentials, cloud accounts, data exports, and API keys move at the speed of the client's IT process. No agent shortens a security review.
- Stakeholder decisions. A choice that needs the founder's yes waits for the founder. The spec review rounds exist partly to batch those decisions while the calendar can still absorb them.
- Production soak. You find out what week one in production looks like by living week one in production. No build speed substitutes for it.
That is why the sprint spends its first three weeks on calls, ADRs, and the spec, and why the client keeps all of it even on a mutual exit.
Handover and the receipt
Handover means deploy, runbook, and walking the client through what they now own, with the first chunks already live as proof the spec builds. The interesting question is what happens after I stop looking.
For the demo, that record is public. The week-one incident log documents its first seven days in production, including a model retired upstream three days after launch, and every entry was cheap to fix because the instrumentation surfaced what broke: heartbeat-supervised workers and per-stage metrics, the same machinery that ships with every sprint. I publish that log because "it shipped" is a claim and an incident log is evidence.
None of this is exotic. It is spec discipline plus machine-checked quality, scheduled around one person's review bandwidth. The full setup, with the eval reports and the commercial terms, is in the operator brief, and the system built this way answers questions right now at the live demo. If you have a scoped problem and four weeks, the DFY sprint is this method pointed at your codebase instead of mine.