Whenever I start a new project, I do not run create-next-app. I fork my last shipped project and have Claude Code strip it down to the bones. Your highest-fidelity starter kit is not a boilerplate repo. It is the last real thing you shipped, with the app logic removed and the design system left standing.
The orthodox scaffold and why it starts you behind
The default move when you start something new is to reach for a blank scaffold. create-next-app. A starter template off GitHub. A boilerplate someone posted that has a nice folder structure.
And then day one goes to rebuilding the stuff you already built once. The blank scaffold has none of your design system. None of your shared components. None of your auth pattern, none of your CI config, none of the table primitives you got right last time. It is clean in the sense that an empty room is clean. It is also empty in the sense that you own nothing in it yet.
That is the part the blank-repo feeling hides. Clean here does not mean ready. Clean means you just threw away your own leverage and signed up to rebuild it from scratch before you write a single line of the actual new thing.
The better primitive: your last shipped project
Here is the move. Your last shipped project is a better starting line than any template, because it is the only scaffold that already has your real work in it.
It has the real design system, the one you battle-tested in production, not a generic one off a starter. It has the shared components you already debugged. It has the patterns you figured out the hard way the first time: how auth wires up, how the data layer is structured, how the build deploys. That stuff is the most expensive part of any scaffold, and you already paid for it.
The orthodox move reaches for a generic template and builds up. The better move forks the thing that already works and subtracts down. Subtracting from something real is faster and safer than adding to something blank.
The duplicate-and-strip move, step by step
Here is the actual workflow. It takes about ten minutes.
Fork the last project folder. Copy and paste the whole thing, give it the new project's name.
Open it in a fresh Claude Code session. Point Claude at the root.
Tell it to strip the app logic. Say it plainly: keep the branding, keep the design system, keep the shared components, keep the table primitives, keep the auth scaffolding and the CI config. Strip everything that belonged to the old product.
Let it work, then read the diff. Claude shows you what it cut. You skim it, catch anything it stripped too aggressively or kept that it should not have, and correct it in the same session.
Reset the obvious project-level stuff. Name, metadata, environment variables, the readme. Now you have a clean repo with all your accumulated scaffolding standing and none of the old product's guts. New project, scaffolded in minutes, on your own standards from line one.
Why Claude Code makes strip work and a template cannot
You could not do this with find and replace, and that is the whole reason a coding agent is the right tool here.
Stripping is judgment work, not mechanical deletion. The agent has to trace the codebase and decide, file by file, which code is domain logic that belonged to the old product and has to go, and which code is reusable scaffold that should stay. A button component stays. The route that fetched the old product's orders goes. The design tokens stay. The data model for the old product's entities goes. A shared table primitive stays. The page that composed that table into the old product's specific dashboard goes.
That tracing is exactly the kind of thing a coding agent is good at and a static boilerplate can never do, because a boilerplate is frozen. It does not know your code. It cannot tell your scaffold from your product. Claude can, if you hand it the project and the keep-list up front. Give it the keep-list first, then the output is crisp.
The line: what you keep, what you cut
The whole move comes down to one clean line.
Keep the scaffold. The design system, the tokens, the shared UI primitives, the table components, the auth scaffolding, the CI config, the folder structure. That is your accumulated leverage. It is the work you do not want to do twice.
Cut the product. The domain models, the business logic, the routes, the data layer that belonged to the old app. That is everything that made the last fork the old product instead of the next one.
If you can name which side of that line a piece of code is on, Claude can strip it. Most code tells you which side it is on the second you ask the question.
The part that compounds
Ten minutes instead of a day is the small win. The real win is what happens over time.
Every project you ship leaves a better starter behind. You improve the design system in project four, and project five forks that richer baseline for free. You harden the auth pattern on one build, and every build after it inherits the hardened version. The scaffold gets better every single time you ship, because the scaffold is just your last real project with the product stripped out.
A boilerplate from two years ago stays frozen at two-years-ago. Your last project keeps moving. That is the difference between a scaffold that compounds and a scaffold that calcifies. Pick the one that compounds.
The closer
Fork your last repo tonight. Point Claude Code at it. Tell it to strip the logic and keep the bones.
Pretty much that.
