Every boilerplate ships the stack. That was never the hard part.
Starters hand you a box of parts and a README. The wiring is what ate my weekends, and with coding agents the slow part moved somewhere else entirely.
Every SaaS starter I ever bought handed me the same box of parts. Auth, a database client, a Stripe integration, a pile of Tailwind, a landing page with a hero section. Then it left me alone in a room with the box and a README.
The parts were never the problem. Bolting them to each other was the part that ate my weekends.
You know the work I mean. The Stripe webhook that has to agree with your database. The RLS policy you forgot about until a user saw someone else's data. The five places a new locale string has to land before the build stops complaining. None of it is hard in the sense of being clever. It is hard in the sense of being endless, slightly different in every project, and exactly the kind of thing you get wrong at 11pm.
I built one SaaS, then a second, and by the third I noticed I was re-typing the same 80 percent before I got anywhere near the part that made the product mine. So I did what every developer does. I started a boilerplate.
Then coding agents got good, and the whole shape of the problem changed.
Here is the thing nobody told me about building with an agent. Generating the first version of anything is now fast. Embarrassingly fast. Point Claude Code at an empty Nuxt project and ask for a login page, and you have one before your coffee is poured. The slow part moved. It is now the second month, when the agent has written forty files and half of them fetch data one way and half another, the auth check exists in three different shapes, and you are the one holding all of it in your head because nothing wrote the rules down.
A boilerplate that only helps the human is solving last year's problem.
So BoiledPlate is built the other way around. The conventions are written for the agent first. There is one documented way to read data, one way to gate a route, one way to add a locale string, one way to take money. Not because I think you are incapable of inventing a second way, but because the agent will invent a fifth and a sixth unless something tells it not to. The rules live in a file the agent reads on its own, next to skills it consults before it touches Supabase or Stripe, next to a read-only view of your actual schema so it stops guessing at column names.
The first session does not start by generating code. It starts by asking you nine questions. What is the product called, which languages, which billing model, do you want the blog, that sort of thing. Then it reshapes the repo to your answers using patches written ahead of time, so the result is the same every time instead of whatever the model felt like that morning. Secret keys go straight into your .env and never pass through the chat.
I am not going to pretend this removes all the work. You still have to build the thing only you can build. But the box of parts is wired together when you open it, and the thing assembling your product knows the house rules.
I sold it once and I keep building on it. boiledplate.ai runs on BoiledPlate, set up by the same nine questions you would get. That is the only honesty test I trust for a starter. If I would not ship my own product on it, why would I ask you to.
Read more
What it actually takes to wire up a Nuxt, Supabase and Stripe SaaS
Picking a Nuxt + Supabase + Stripe + Resend stack is the easy decision. Here is the wiring each piece really demands, and where a SaaS starter saves you weeks.
How to set up Stripe subscriptions in a Nuxt + Supabase app
The five decisions behind Stripe subscriptions on a Nuxt + Supabase stack: plans in config, checkout, webhooks, RLS-enforced access, and the customer portal.
Write your conventions for the agent, not the next hire
An agent cannot smell a codebase. Give it three ways to do one thing and it adds a fourth. Here is how BoiledPlate keeps agent output consistent past month three.

BoiledPlate