This week I sat through a blast-radius audit for a piece of software I built in April. Item by item: one Supabase project, one Vercel deployment, one Cloudflare DNS record, three API tokens, one repo. Each with an exact identifier, a list of everything that consumed it, and a SAFE or UNSAFE verdict before anything got deleted (VAS-1639, if you’re playing along at home).
The Supabase project was 82 days old. Nothing else in my stack had ever spoken to it.
That’s not a dependency graph. That’s a headstone.
The sprint worked, which is the annoying part
This would be an easier story to tell if the build had gone badly. It didn’t.
VAS-446 was my second gstack sprint — greenfield this time, a cross-project status dashboard at dashboard.vasko.com.au. The autoplan ran four review phases with two independent voices each: eight reviews, roughly 125 findings, synthesised into a 1,312-line PLAN.md. It absorbed four user challenges I’d signed off on, scheduled five architectural must-fixes for day one, and — my favourite part — corrected my wall-clock estimate from a fantasy 6–8 hours to an honest 14–16. It was right.
The thing shipped. Sixteen seeded repos, eleven paused projects in a tidy table, magic-link auth, isolated API clients so a Linear outage couldn’t take down the GitHub data. To spec. The machinery is not the villain here.
Day one: the mirror
I opened the deployed dashboard and four of my five active project cards said the same thing: not yet documented.
The design’s load-bearing primitive was a wiki convention — each repo carries a /docs/dashboard.md, the dashboard extracts a “Current Focus” heading, and the cards stay meaningful as long as I keep those files current. The dashboard’s very first act in production was to faithfully report the fatal flaw in its own design. Manual capture was the foundation, and I was never going to do manual capture. My work flows through Linear, Claude Code and Cursor. None of it touches a markdown file on the way past.
There was a second, quieter miss. PLAN.md line 128 — an acceptance criterion requiring a proof-of-concept wiki file for one repo — shipped unbuilt. Eight reviews had approved the plan. The test suite was green. Nobody checked the artefact against the checklist. I filed that one as VAS-449: the plan gets reviewed, the tests get run, and the deliverable falls through the gap between them.
Forty-eight hours later: the product was a chat message
Within two days I’d stopped tweaking the dashboard and started interrogating the job. What did I actually want when I sat down to triage? Not a wiki. A status report with a recommendation.
So I ran an experiment. I asked Sally — my Telegram-resident agent, who already has the Linear MCP and repo access — for a status and priority report on three deliberately different projects: one mid-sprint, one pre-launch, one maintenance-mode content site with almost no ticket activity.
All three reports were excellent. Confident on phase, specific on blockers, sensible on next actions, and each one shaped to its project — the content site got commit-cadence and conversion-funnel analysis where a tickets-and-PRs dashboard would have rendered an empty card.
I turned those three outputs into the spec for a v2 (VAS-457): AI synthesis instead of wiki extraction, on-demand instead of cron, compressed cards on the front page. It was the best-evidenced ticket I wrote all quarter.
I cancelled it a month later. No ceremony. I just noticed one day that it had been sitting in the queue behind everything else, and that I hadn’t visited the dashboard URL since May.
Why it died
Here’s the central lesson, stated plainly: I built a destination for answers I could already ask for. A surface you work in earns a daily slot. A surface that reports about your work has to win that slot against a chat window that’s already open — and it loses, every time, because the chat window answers follow-up questions and the dashboard doesn’t.
By July, my mornings belonged to UPS — the Linear-backed planner I’d built in the meantime — because I allocate my day in it. It’s a working surface. The dashboard only ever described work happening elsewhere, and describing is not a job that survives contact with an agent who can describe on demand.
The capability didn’t die, though. This is the part worth keeping: the entire v2 spec — the card format, the link-every-claim discipline, the adaptive framing — ported straight into a Sally skill (VAS-1640). An app became a prompt. The build cost of the dashboard was a 16-hour sprint plus ten weeks of idle infrastructure; the build cost of the thing that replaced it is roughly a page of instructions.
Clean your house
Now the uncomfortable bit, because agentic development has a side effect nobody puts in the demo videos.
When shipping costs a weekend instead of a quarter, you ship more. That’s the point. But it also means you accumulate deployed, credentialed, half-alive projects at the same speed — every one carrying a Supabase project, a DNS record, live API tokens and a Vercel bill for the privilege of being ignored. AI-driven development doesn’t just produce features faster. It manufactures tech debt and defunct projects faster too, and the muscle most of us haven’t built is the one that admits it.
So the teardown got the same rigour as a build, and I’d argue it deserves more:
Be honest first. “I don’t go to the URL” is a complete argument. I didn’t need a retro workshop; I needed to stop pretending a paused project was a resting one.
Sweep the learnings before you delete anything. Four things walked out of the wreckage: the v2 spec as a Sally skill, the “what changed since Monday” delta idea as a query instead of a UI, the VAS-449 process gap for my agent tooling, and this article. If you tear down without the sweep, you paid full price for the lesson and left it on the table.
Audit the blast radius, then gate every delete. The classic trap in my stack is a shared credential — revoke the dashboard’s Linear key and discover it was also Sally’s. The audit proved each token was project-specific before anything got revoked, and every delete waited for a per-item go. Then the survivor checks: the three neighbouring production apps loaded, and Sally did a benign Linear read, before I called it done.
That April decision to give the dashboard its own Supabase project instead of reusing an existing one — made for blast-radius reasons at build time — is exactly what made the teardown a clean afternoon instead of a forensic week. Decommissioning starts at architecture time. You’re just not invited to that meeting yet.
The bill
One sprint, ten weeks of idle infra, one clean teardown, one skill, one process fix, one article. I’d pay it again.
Not because the dashboard was secretly a success — it wasn’t, it’s deleted — but because the v2 insight was only reachable through a v1 in production. You cannot scope against use without something in use. The discipline isn’t avoiding dead projects. It’s refusing to let them die quietly, still holding your credentials, teaching you nothing.