Comparison
SaaS Boilerplate vs Vibe Coding
An agent does not need a generated app. It needs a foundation with written rules, so the conventions it follows are yours and not whatever the last session invented.
Lovable will turn a sentence into a deployed React app with a backend behind it in a few minutes, and for a certain kind of project that is the whole answer. A founder who does not write code, an internal tool that has to exist by Friday, an idea that needs a URL before it deserves an architecture: a prompt-to-app builder wins those outright, and nothing below argues otherwise.
The saas boilerplate vs vibe coding question is really about what happens in month three, when the app needs organizations, billing webhooks that survive a retry, and an admin screen, and the person asking for those is a coding agent rather than a person. This page is about giving that agent something to stand on.
We have a direct interest: the Hype Stack template ships rules for coding agents. Read the last section as interested and the rest as the part worth reading either way.
Three ways to get an app out of a model
The middle column is the one most developers actually use, and it is where the phrase "vibe coding does not work" usually comes from. It is not that the model is bad. It is that a model infers patterns from what is already in the repository, and in an empty one there is nothing to infer from, so it invents patterns, differently each time.
What an agent reads before it writes
Here is the footprint of the rules in a scaffolded project. Rows marked with a plus were written at create time by the CLI, in the native format of every assistant you named. The content is authored once and converted, so Cursor, Claude Code, and Codex are reading the same guidance.
- AGENTS.mdCodex and OpenCode read this one file. Always-on rules inline, scoped rules linked.
Codex and OpenCode read this one file. Always-on rules inline, scoped rules linked.
- CLAUDE.mdClaude Code's entry point, sharing the same file.
Claude Code's entry point, sharing the same file.
- .cursor
- rules
- backend-error-handling.mdcNo try/catch. Errors reach central middleware.
No try/catch. Errors reach central middleware.
- frontend-data-fetching.mdcOne way to call the typed SDK.
One way to call the typed SDK.
- backend-features.mdcHow a feature folder is laid out.
How a feature folder is laid out.
- testing-workflow.mdcWhere tests live and what they must not be.
Where tests live and what they must not be.
- no-em-dash.mdcYes, really. Consistency is the point.
Yes, really. Consistency is the point.
- .agents/skillsEight skills from skills.sh, pinned by content hash in skills-lock.json.
Eight skills from skills.sh, pinned by content hash in skills-lock.json.
- .github/instructions/The same rules, in Copilot's format, if you picked it.
The same rules, in Copilot's format, if you picked it.
- apps/backend/src/middleware/errorThe code the rule above points at. Already in the template.
The code the rule above points at. Already in the template.
Paths from the template repository and the AI overview docs; rule names abbreviated. The full set is 13 rules, 8 skills, and 4 custom lint rules, written for Cursor, Claude Code, Codex, Copilot, Windsurf, OpenCode, and T3 Code.
The rules are short and specific: how errors reach the central middleware, how data fetching uses the typed SDK, how a backend feature is laid out, how tests are written and which tests are not worth writing. They are the things a senior engineer says in the first code review, written down so the agent hears them before the first commit.
What that changes per request
One request, with a foundation
You describe the feature, not the architecture
"Members can pin a project to the top of the switcher." You do not say where the endpoint goes or how the error is handled, because that is already decided.
The agent reads the rules first
It finds the feature layout, the data-fetching convention, and the error rule before it writes a line. The change lands in the same shape as the code around it.
AGENTS.md, .cursor/rulesThe gates catch the rest
Typecheck in about nine seconds and oxlint in about two. A wrong type or a forgotten permission check fails before you look at it, and the agent fixes it without a review cycle.
typecheck 9s, oxlint 2sYou review the part that is yours
Auth, organizations, and billing were reviewed before they shipped as packs. The diff you read is the pin feature, and nothing else.
Gate timings from the AI toolkit page for the template on a current laptop. Yours will differ; the point is that they are seconds, not minutes.
“The same model produces good code in a codebase with conventions and slop in one without.”
25
rules and skills the agent reads before writing: 13 rules, 8 skills, 4 custom lint rules
3x
fewer retries before a change lands, measured on the same change in a blank repo and in the template
7
assistants the rules are written for, in each one's native format, at create time
Two beliefs worth correcting
A good enough model will infer my conventions from the code, so I do not need to write rules.
In a repository with one way to do things, yes. In a repository the agent built from nothing, the conventions are whatever it picked last session, and by week three there are four of them. Rules are how you tell it which one, and an afternoon writing them changes output more than any model upgrade.
If the model can write a login flow, I do not need a kit's login flow.
A model writing signup, organizations, or Stripe webhook handling produces the version a thousand repositories wrote, with their errors. Webhook idempotency is the usual one: Stripe retries and reorders, and code that assumes each event arrives once double-counts and looks fine until it does not. Starting from code that already handles it leaves the agent free to work on what is yours.
Neither belief is stupid. Both are what a smart person concludes after one good afternoon with an agent and before the first bad month.
Which one fits you
Who is going to write the second half of the product?
Pick it when nobody on the project writes code, or the app has to exist by Friday.
- A real URL in minutes, and a builder that does not need a developer in the room
- Right for validation, internal tools, and anything likely to be retired inside a year
- Connect your own database on day one if you think you will ever want out
Pick it when a coding agent will write the product and you want it to write yours, not a generic one.
- Claude Code, Cursor, Codex, or Copilot in a repository that tells them how things are done
- Auth, organizations, and billing as reviewed packs, so the agent's attention goes to what is specific to you
- Free MIT template, your own hosting, and no credit meter on a stubborn bug
The productive pattern most people land on is the left column for the first afternoon and the right one afterwards. The question is only what the agent works in from day two.
Below is the stack this page recommends for an agent to build on: the Better Auth SaaS starter, the joyful layout, and Stripe billing. The rules come with the template whichever packs you pick.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeInside the stack
What each pack gives you
Source code, not a dependency. Every pack lands in your repository across the surfaces the feature touches.
Authentication, organizations, roles, sessions, and a full admin app, powered by Better Auth on your own Postgres.
- Email & Google login
- Organizations & members
- Roles & permissions
- Admin app & dashboard
Questions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.