From generator to colleague: a project template for shipping web apps with Claude Code

I'm a Product Manager, not a developer. Over the past year or so I've built a handful of small web apps with Claude Code, and after the second or third project I noticed I was doing the same setup work every time: same scramble to remember how I'd structured things last time, same hunt for the prompts and reference files that had worked.

Eventually I made a template to start from, which has now lived on GitHub for about four months and been improved over four distinct projects. It's small and opinionated. It captures patterns I've borrowed from decades around good engineers: specifications before code, written reasoning that outlives the conversation, reviews proportional to risk, separation of concerns. None of it is novel. The point is having it all in one place, ready for Claude to pick up from the first session.

A few people, after reading the original template post, asked me some version of "this looks great but I wouldn't know where to start". Fair. The template assumed you'd already worked through the painful business of choosing a tech stack, a hosting provider, a database, an email service, somewhere to put your secrets. For a non-technical person who just wants to ship a small web app, those decisions are really tricky.

My most recent improvement is to add some onboarding wizard thinking for how to set the template up when a new project starts.

What the wizard does

The first time someone downloads the template now and runs Claude in the folder, Claude doesn't just sit there waiting to be told what they want to build. It asks who they are.

The point is to defuse the blank-canvas problem. Dropping into a fresh Claude Code session with an idea in your head can be intimidating if you don't think like a Product Manager, especially if you've never used a command line before. The wizard removes the question of where to start by starting the conversation itself. Which, I realise as I type this, means the AI is now prompting the human rather than the other way around. Hilarious, but it works.

The wizard fires automatically on first session. Four short questions: your name, your background, how direct you want it to be, how deep you want the technical explanations to go. There's an optional fifth question for anyone doing product work alongside the building.

Two minutes, tops. After that, Claude knows whether it's talking to a seasoned backend engineer who wants the bluntness dial set to eleven, or someone who's never raised a pull request and would prefer a bit of warmth. It calibrates every response for the rest of the project accordingly.

The prompt fires exactly once, on the first session, using a hook. No config file to edit, no docs to read. Your profile lives in a gitignored file on your machine, so personal details stay out of it even if the project ends up public on GitHub.

The bit I like most is what happens at the end of the wizard. Instead of dumping you into a blank prompt, Claude explains what's coming next: a project outline conversation based on the original idea, the specification, the phased build. It asks whether you've got any existing notes or mockups to drop in. The first real conversation starts with context, not from scratch.

Under the hood

The wizard is one fix. The other lives underneath: the template now makes the infrastructure choices for you, opinionatedly, before you write a line of anything.

One platform, fewer decisions

Everything defaults to Cloudflare. Hosting, database (D1), object storage (R2), email. One account, one place to look, one bill. I've moved my own projects onto this stack over the last few months, and it's by some margin the easiest infrastructure I've used for Claude-assisted projects. Things mostly just work, and when they don't, Claude knows the platform well enough to debug without much hand-holding.

You don't need a view on database choices before you start. You don't need to have an opinion on Vercel versus Netlify versus your own VPS. The template's view is: Cloudflare, until something specific forces you off it. That's more than enough to get a small self-hosted project up and running. And free (or almost free) to start, forever unless you outgrow the very generous free tier!

Review proportional to risk

Hobby projects or not, deploying things to the public internet is a bit scary. What if I'd shipped something stupid? What if Claude had introduced a security hole I didn't have the eye to catch? I'm not a developer, only someone who's spent a long time around developers.

So I borrowed an idea from a recent Claude Code meetup, where the case for adversarial agents was made. I told Claude to always post a change to GitHub as a pull request (PR), and then set up a skill that reviews every PR before it gets merged and deployed. It spawns a small team of sub agents: a technical architect, a security reviewer, a technical writer who keeps the documentation in step with the code, sometimes a devil's advocate that I rather enjoy because it occasionally tears my ideas apart. Each agent starts from its own context, with only the PR and the project documentation as input. They discuss, they agree on recommendations, they post a single review back. (More detail on the original multi-agent setup in this earlier post.)

The reason this doesn't feel like Claude marking its own homework is that each agent reads the code fresh, with a distinct brief. The review surfaces things I or Claude wouldn't have caught alone. It's the closest I can get to a gate before deploying, and on a hobby project run by a single non-developer, that gate matters more than it would on a properly staffed engineering team. Would I trust this approach if real users depended on it? Probably not. For what I'm building, it's plenty, and I enjoy the process.

Until recently, the full team ran on every PR. Now it triages first, to save tokens and match review depth to risk. Tiny docs tweaks get a quick single-reviewer pass; anything touching the database, auth, CI or secrets escalates to the full team. You're told the tier and why before the review runs, so you can override if you disagree.

After each review, findings get sorted into three buckets: apply now (Claude does it after you confirm), your call (a scope or UX decision for you to make), or track as a GitHub issue. No review comments and up as "we'll do that later" floating in conversation history and evaporating quietly.

Decisions that outlive the PR

The template always treated specifications, tests, and pull requests as three layers of context for the same project. Recently I also added Architecture Decision Records to capture important choices.

Specifications capture what we're building, before we build it. Pull requests capture what changed in this specific slice, and why. Neither survives well on its own as a record of the bigger choices: the ones where you agonised and debated two options before going one way. Those decisions otherwise risk being forgotten between sessions, and you find yourself re-arguing them months later.

ADRs are the fourth layer. Short notes, written at the moment of the decision, capturing the alternatives considered and the reasoning that won. When Claude spots a decision being made that will outlast the current PR, it asks whether to write one up. Future sessions search the folder before making similar calls and either follow the existing reasoning or note explicitly why the context has changed.

It's a Michael Nygard pattern from over a decade ago, and it's the single most useful addition I've made in months. Long-running AI-assisted projects fail mostly in one specific way: decisions get forgotten between conversations. ADRs are the antidote, and they're light enough to actually use.

What's next?

I keep iterating on this template as I build more web apps and come across new ideas from others in the Claude Code community.

As I build more projects on this template, the thing that keeps getting me is how it makes Claude Code feel like a colleague rather than a generator. Claude reads the room and constantly asks the right questions. The reviewers argue with me and Claude. The ADRs remember what we decided. The instincts I built as a Product Manager turn out to be the instincts this kind of collaboration runs on. Which is the bit I built all of this for, even if I didn't realise it when I started.