Source: https://www.hype-stack.dev/stacks/saas-boilerplate-vs-vibe-coding # 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 | | Lovable | Agent in a blank repo | Agent in a template with rules | | --- | --- | --- | --- | | First screen | Minutes, from a sentence, with a public URL. | Longer: run the CLI, start Postgres, then ask for the first feature. | An hour, once the agent has picked a framework, a database, and a folder layout. | | Where conventions come from | Invented per session. Four ways to fetch data by week three. | The platform's generator. Consistent inside one project, opaque to you. | Written down in the repo. One way to fetch, one way to handle errors, one way to structure a feature. | | Auth, organizations, billing | Generated from the prompt, with the same mistakes. | Generated from the prompt, with the mistakes a thousand generated repos made. | Shipped as reviewed packs. The agent spends its attention on what is specific to you. | | Feedback loop | You look at the preview and describe what is wrong. | Whatever lint and tests the agent set up, if any. | Typecheck, oxlint, and tests already wired, so a bad guess fails in seconds without you reading the diff. | | Cost shape | Credits per attempt, plus Cloud and AI usage once live. A hard bug costs more than an easy feature. | Your AI tool's subscription and your hosting. | The same, plus a free MIT template. Paid packs are one-time; All-Access is yearly. | | Leaving | Nothing to leave. | Nothing to leave. | Code export on paid plans. The app assumes the platform it was born on. | [What the AI toolkit actually ships](/ai-toolkit) 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. **your-app** — written at create time - AGENTS.md (added) — Codex and OpenCode read this one file. Always-on rules inline, scoped rules linked. - CLAUDE.md (added) — Claude Code's entry point, sharing the same file. - .cursor - rules - backend-error-handling.mdc (added) — No try/catch. Errors reach central middleware. - frontend-data-fetching.mdc (added) — One way to call the typed SDK. - backend-features.mdc (added) — How a feature folder is laid out. - testing-workflow.mdc (added) — Where tests live and what they must not be. - no-em-dash.mdc (added) — Yes, really. Consistency is the point. - .agents/skills (added) — Eleven skills from skills.sh, pinned by content hash in skills-lock.json. - .github/instructions/ (added) — The same rules, in Copilot's format, if you picked it. - apps/backend/src/middleware/error — The code the rule above points at. Already in the template. 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** 1. **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. 2. **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/rules) 3. **The 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 2s) 4. **You 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. **The same model produces good code in a codebase with conventions and slop in one without.** - **28** rules and skills the agent reads before writing: 13 rules, 11 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 - **The agent will work it out:** A good enough model will infer my conventions from the code, so I do not need to write rules. **It infers what is there:** 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. - **Generated is as good as reviewed:** If the model can write a login flow, I do not need a kit's login flow. **It writes the common version:** 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?** - **Lovable:** 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 - **Agent plus template:** 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. Comparing two specific builders instead: [Bolt vs Lovable](/stacks/bolt-vs-lovable) and [Lovable Alternative](/stacks/lovable-alternative), and comparing boilerplates to each other: [Best SaaS Boilerplate 2026](/stacks/best-saas-boilerplate-2026).