Throwing away the stack five days in
June 17, 2026
I lock the stack on a Thursday. By the following Tuesday I've deleted the app I started building.
Not because it was broken. Three signals land at once, and when I map them, the math is different.
The original pick
I'm building a patient management app for a friend who runs a private therapy practice. For the tech stack I run a proper evaluation: five candidates, scored on compatibility with the domain, cost, deployment simplicity, and how well Claude Code handles them. The winner is Next.js on Vercel with Neon Postgres. One framework for the frontend and the API layer, one platform, serverless edge routing. Locked. Scaffolded. Starting on data modeling.
Five days later, three things are true that weren't true when I made that call.
Three signals
The product needs four apps, not one. A web dashboard, a mobile companion, a landing page, a job board for the portfolio. Next.js handles one app cleanly. Splitting into multiple Next.js projects means the host bills per project and the architecture gets messy in ways I can already see.
The free tier blocks org repos. I'm building in a personal GitHub org. Both Vercel's free plan and Netlify's free plan block deployments from org repos without a paid upgrade. That's a $20/mo floor I assumed wasn't there when I picked either of them.
Cloudflare Containers went generally available one month before this moment. That's why I didn't pick it when I ran the original evaluation: it wasn't a live option yet. Now it is. Containerized Node.js on Cloudflare's edge infrastructure, running as a proper server process rather than serverless.
Any one of these is a yellow flag. All three at once is a decision.
The thing that makes deletion possible
Before I touch anything, I tag the repo at its current state.
That one action changes the psychological frame. "I'm deleting working code" becomes "I'm making a reversible decision." These are the same operation. They don't feel the same. The tag is why they can.
Five days of scaffolding, no production data, no users depending on any of it. The original work is still there, named, findable. So the question of whether to keep it becomes a real question instead of a fear.
Three hours to a new stack
I set a hard time limit on the decision session and open it with a clear question: what fits a multi-app SPA and API architecture, runs under $15/month, has no org-repo restrictions, and Claude Code handles well?
I have Claude Code run the candidate evaluation in parallel threads, each thread scoped to one evaluation axis. No sequential deliberation where I reason through one candidate at a time. Parallel comparison, scored explicitly.
Three hours later the session closes with a decision.
New stack: Cloudflare Containers for the backend, Hono on Node as the API framework, Cloudflare Pages for the frontend SPA, Neon Postgres for the database with a direct connection. The estimated monthly cost drops from roughly $40 to roughly $7-10.
One thing that came out during the scaffolding: connection pooling via Cloudflare Hyperdrive is unreachable from inside a container, so that gets dropped. Direct connection to Neon it is. A small discovery, filed and moved on.
The delete
The new scaffolds go in. Then the old app gets deleted. About seventy files.
The tag is right there. None of that makes clicking delete comfortable. It makes it sensible.
What makes it hard isn't the loss. It's what re-picking implies about the original pick.
The six-step shape
Looking at what I actually did, there's a pattern worth naming:
Tag before you burn. Lock recoverability before touching anything. A tag turns a deletion into a revert.
Timebox the decision. The hard limit does real work: it forces closure instead of open-ended deliberation that could run for days.
Fan the research out. Parallel evaluation threads, one per axis. Not sequential thinking.
Score explicitly. Vague "this feels better" comparisons produce vague decisions. A scored comparison produces an outcome.
Write the ripple list before you scaffold. Know what else changes before you start building the new thing.
Name the triggers honestly. Three specific signals, not "I found something better." Honest naming is what makes the pattern repeatable. If you can't name the triggers, you can't know when to apply it next time.
The three-hour close is the part that surprised me. A decision like this used to be a weekend at minimum. The parallelism is what changed it: AI running multiple evaluation threads simultaneously, each to a scored conclusion in the same session. Not faster typing. A different shape of thinking.
A note on pace
This went fast because there's no live product, no team, no commercial deadline that forced the original stack to stay. For a project with users in production, the same pivot costs more: migration planning, rollback, coordination, timing. The pattern still applies. The timebox gets longer. The stakes change. The principles don't.
The old app is in git history. The new scaffolds are in. The build continues.
#AIEngineering #CloudflareContainers #BuildInPublic #SoftwareArchitecture #AgenticEngineering