Pick for training-data density, not for taste
A language model is good at your stack in direct proportion to how much of that stack it has seen. This is not a subtle effect. In a popular, stable, heavily-documented framework, the model produces code that works on the first try and follows the idioms a human expert would use. In an obscure or very new one, it produces code that looks exactly as confident and is subtly, expensively wrong: imports that do not exist, config keys that were renamed two versions ago, APIs it has effectively invented by analogy.
The failure mode is the problem. The model does not get quieter or hedge when it leaves familiar territory. It hallucinates at exactly the same self-assured register it uses when it is right, which means you cannot tell from the output whether you are in the well-trodden part of its knowledge or the improvised part. The only reliable lever you have is to stay in the well-trodden part on purpose.
What to pick, if you want an answer
People asking this question usually want a recommendation, not a survey of the landscape. So: for a web app with users, accounts, and stored data, which is the thing most vibe coders are actually building, use React and Next.js on the frontend, and Supabase or Firebase for authentication and the database.
That combination is not the most elegant thing you could choose, and people with strong opinions will tell you so. It is the combination the model has read the most code in by a wide margin, which means it is the one where the model behaves less like an intern and more like someone who has done this before. When you are relying on a collaborator who cannot ask you clarifying questions, fluency beats elegance every time.
| Decision | Take the boring option | Why it matters for vibe coding |
|---|---|---|
| Frontend | React + Next.js, or plain HTML for small things | The densest training data in existence. Also the default target of most AI app builders, so tooling assumes it. |
| Styling | Tailwind | Models are excellent at it, and it keeps styles next to the markup, so the model can see and change both at once. |
| Auth + database | Supabase (Postgres) or Firebase | Both give you real auth without building it, which is the one thing you should never hand-roll. Their rules systems are where the danger lives. |
| Hosting | Vercel, Netlify, or Firebase Hosting | Push to git, it deploys. Removes an entire class of environment bug you would otherwise debug at launch. |
| Payments | Stripe | Do not get creative here. Stripe has the best docs on the internet, which means the model has read them. |
Supabase or Firebase?
The honest answer is that either will work, and the choice matters far less than whether you configure it correctly. But there is a real difference in how they fail, and that is worth knowing before you commit.
- Supabase is Postgres. You get real SQL, real relations, and real constraints, and if the project outgrows the platform, it is still just a Postgres database you can take with you. Security is Row Level Security: policies written in SQL, attached to each table. RLS is genuinely powerful and genuinely easy to leave off, and a table with RLS disabled is a table the entire internet can read.
- Firebase (Firestore) is a document store, so it is more forgiving early. You can throw a shape at it and move on. Its security is a rules file in its own small language. That file is where most Firebase disasters live, and the reason is a single line that every tutorial starts with and nobody deletes.
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
// "I'll fix this before launch." Every founder, once.
allow read, write: if true;
}
}
}This is what the scaffold gives you, and it is what a shocking number of live apps still have. 'allow read, write: if true' means any person on the internet, with no account, can read and overwrite your entire database.
We find that file, unchanged, in production apps constantly. Not because anyone decided to ship it, but because it was invisible. It never threw an error, never turned anything red, and made every feature work smoothly during development. It is dealt with properly in Auth, roles, and database rules, which is the chapter to read if you read only one.
The tempting choices that trap you
A stack you picked because it is new
The framework that launched last quarter has the best marketing site and the least training data. You will spend your time correcting confident nonsense instead of building, and every wall you hit will be one where there is no Stack Overflow answer to fall back on, because you are among the first thousand people to hit it.
A no-code tool you will outgrow in a month
These are excellent for validating an idea and genuinely good at what they do. The trap is the ceiling. The moment you need one thing the platform did not anticipate, you are not extending the app, you are rebuilding it somewhere else. Fine if you knew that going in. Painful if you found out at 30,000 users.
Your own authentication
The model will happily write you a login system. It will have a users table, hashed passwords, and a session cookie, and it will work perfectly when you test it. It will also, with high probability, have a subtle flaw in session handling, password reset, or token expiry that you are not equipped to find and that the model is not going to volunteer.
Write the stack down, then stop deciding
Once you have chosen, put it in a file at the root of your project, such as a CLAUDE.md or .cursorrules, or whatever your tool reads automatically, and let it into the model’s context on every single request.
# Stack. Do not deviate without asking.
- Next.js 15, App Router (never the Pages Router)
- TypeScript, strict mode
- Tailwind v3 for all styling. No CSS modules, no styled-components.
- Supabase for auth + Postgres. RLS is ON for every table.
- Deployed on Vercel.
# Rules
- Never put a secret in a NEXT_PUBLIC_ variable.
- Every new table needs an RLS policy in the same change.
- Server-side checks for anything about permissions. UI checks are cosmetic.Cheap to write, and it removes a whole category of drift: the model reaching for a second styling system, or an ORM you never installed, halfway through a long session.
That last block does double duty. It keeps the model consistent, and it is a standing instruction about the things it would otherwise get wrong. You are pre-writing the correction you would have had to make later, which is the central move of the next chapter.