One Spec. Seven Phases. A Production App.
Context
Brookfield Digital runs a microgreen operation alongside its software business. Managing grow cycles — seeding trays, scheduling, tracking harvests, delivery packing — was handled manually: spreadsheets, mental math, and a rough React prototype that the founder had built himself.
The prototype had hardcoded dates. It couldn’t track multiple concurrent grow cycles. It didn’t know about delivery schedules or seed burn-down. It was useful for understanding the domain, but it wasn’t a product.
In April 2026, the founder wrote a build spec in a single Paperclip issue (BRO-680): “Brookfield Grow Ops — Build & Deploy Spec.” The spec described a microgreen production management app: a Cloudflare Workers + D1 + Hono + Vite React stack, single-operator, deployable to grow.brkdllc.com. It referenced the existing prototype as domain reference, not as code to preserve.
Then it handed the spec to agents.
What Was Done
The spec decomposed into seven execution phases, each tracked as a child issue:
| Phase | Issue | Scope |
|---|---|---|
| Phase 1 | BRO-681 | Scaffold monorepo and D1 migrations |
| Phase 2 | BRO-682 | Hono API CRUD |
| Phase 3 | BRO-683 | Frontend port |
| Phase 4 | BRO-684 | Schedule generator |
| Phase 5 | BRO-685 | Delivery view and seed burn-down |
| Phase 6 | BRO-686 | Deploy |
| Phase 7 | BRO-689 | Acceptance, auth enforcement, and real-use shakedown |
Two additional issues were filed mid-sprint: a Design Redirect (BRO-687) — the founder decided mid-build that the app should have a “friendly consumer web aesthetic” rather than a utilitarian operator tool — and a Mobile nav density reduction follow-up (BRO-688) after the design pass.
All nine issues completed successfully. The app was deployed to production.
Post-Launch: Real Use Surfaced Real Bugs
The most telling part of this story isn’t the build. It’s what came after.
Two weeks after launch, the founder filed two new issues — not from a code review or a QA pass, but from actually using the app:
BRO-690: “Prod has old cycles and I want to start a new one. Not sure how to trash old cycles and properly start something new.” — This was a UX gap: no end/cancel cycle workflow. The agent designed and implemented it as two child issues (BRO-691, BRO-692), including an unexpected discovery that the dev and prod Worker names were colliding, allowing dev deploys to clobber production.
BRO-696: “Not sure cycle timing is right.” — A harvest alignment bug: the schedule generator was snapping forward to an incorrect date. The agent diagnosed it as a clamped back-shift issue and fixed it (BRO-698), along with a related delivery-target day-of-week alignment fix (BRO-697).
Both post-launch issues were filed in natural language, resolved by agents, and closed. The founder never touched a git branch.
Verifiable Outcome
| Metric | Value | Source |
|---|---|---|
| Agent-created issues | 13/15 closed (87%) | createdByAgentId field per issue |
| Child issues (phases) | 13/15 closed (87%) | parentId field per issue |
| Execution phases | 7 (scaffold → API → frontend → scheduler → delivery → deploy → acceptance) | BRO-681 through BRO-689 |
| Design revision mid-sprint | Yes (BRO-687: “friendly consumer web aesthetic”) | Child issue |
| Post-launch bugs filed | 2 (BRO-690, BRO-696) | Issue thread |
| Post-launch bugs resolved | 2/2 | Both done |
| Production deployment | Yes (grow.brkdllc.com) | BRO-686 + spec in BRO-680 |
| Founder engagement | Used in production; filed real operational bugs | BRO-690, BRO-696 |
Why This Story Matters
The Brookfield Grow Ops build is the most complete illustration of the agentic development model in this archive.
A single spec issue — written in plain language by a non-technical founder who happened to also be the operator — became a 15-issue execution that shipped a production application. The founder didn’t write JIRA tickets, didn’t manage a sprint board, and didn’t translate requirements into engineering tasks. They wrote what they wanted, and agents built it.
The post-launch story matters as much as the build: the founder used the app, discovered real operational gaps, described them in plain language, and agents fixed them. The system didn’t stop at “shipped” — it continued operating as the support and maintenance layer after launch.
The 87% agent-created statistic captures the ratio, but the shape of the engagement captures something harder to measure: a human describing a goal, and software appearing.