Vibe coding essentials: 8 things to set up before anyone uses your app

Why “it works” isn’t enough

An AI model building your app is trying to make the thing you asked for work when you click it. It isn’t, unless asked, thinking about who else can read your database, what happens to your API key, or what a bad change does to real users’ data.

That gap is fine for a personal project. It stops being fine the moment someone else signs up. Simon Willison’s rule for professional use of AI-written code is a good north star: don’t ship code you couldn’t explain to someone else (Willison). You don’t have to reach that bar to launch a small app — but these eight essentials get you most of the safety for a fraction of the effort.

1. 1
   Version controlEvery working state saved, so any change can be undone.
2. 2
   Secrets out of the codeAPI keys live in the platform's secrets settings, never in files.
3. 3
   Data access rulesThe database decides who can read and write each row.
4. 4
   Sign-in you didn't buildUse the platform's or a provider's login, not a custom one.
5. 5
   A check you can rerunA short list of things to click, or automated tests, after every change.
6. 6
   Separate test and liveExperiments never touch real users' data.
7. 7
   Spending limitsCaps and alerts on every usage-billed service.
8. 8
   Backups and an exitRestorable data, and code you can take elsewhere.

1. Version control: make every change undoable

Version control records every working state of your project so you can compare versions and go back. It’s the safety net for every other step.

If you’re in an app builder, check whether it can sync to GitHub. Lovable, for instance, syncs changes both ways with a repository in your own GitHub account, which is private by default (Lovable). In a coding editor, that means a git repository and a commit every time something works.

Two-minute check: can you name the last working version, and could you restore it right now?

2. Secrets: keep keys out of the code

API keys, database passwords and tokens must never be written into your code files. Code gets copied, shared, pushed to GitHub and sent to browsers — and secrets go with it.

This happens at scale. GitGuardian counted about 28.6 million new secrets in public GitHub commits in 2025, and found that commits co-authored by Claude Code leaked secrets at roughly twice the rate of public commits overall (GitGuardian).

28.6Mnew secrets found in public GitHub commits in 2025GitGuardian

64%of valid secrets found in 2022 still worked four years laterGitGuardian

~2×leak rate in Claude Code co-authored commits vs all public commitsGitGuardian

Put secrets in the platform’s secrets or environment settings instead. If you use GitHub, its push protection blocks pushes that contain recognised credentials; the user-level version is on by default for public repositories, while repository-level protection must be switched on by an owner (GitHub).

Two-minute check: ask the AI, “List every API key, password or token in this project and tell me where each one is stored.” Anything in a code file gets moved, then rotated — a leaked key stays leaked even after you delete it.

3. Data access rules: lock the database by default

Many app builders connect to a hosted database, often Supabase. Supabase’s documentation is direct: enable row level security on every table in an exposed schema, because without it any role with access to the table can read and write all of it (Supabase).

Supabase is also tightening defaults. New tables in the public schema are no longer automatically reachable through its Data API: the change became the default for new projects from 30 May 2026 and applies to all existing projects from 30 October 2026. Supabase cites AI tools creating tables without human review as one reason (Supabase). If your app suddenly can’t read a table after that date, this is likely why — and the fix is an explicit grant, not switching security off.

Two-minute check: open your database dashboard and confirm that every table has row level security on and a policy that matches who should see what. Then ask the AI to explain each policy in one sentence.

4. Sign-in: don’t build your own

Login systems look simple and are easy to get subtly wrong: password storage, reset links, sessions, rate limits. Use the sign-in your platform provides, or an established provider, and resist asking the AI to “add a login page” from scratch.

Two-minute check: can you name which service stores your users’ passwords? If the answer is “my database, in a table the AI made,” change it before launch.

5. A check you can rerun after every change

AI changes have side effects. Fixing the checkout page can quietly break the profile page. You need a way to notice.

Start with a written list: the five to ten things a user does, in order. Click through it after every change. When that list gets long, ask the AI to turn it into automated tests and to keep them passing — tests are one of the best uses of an AI coding tool.

6. Keep test and live separate

Never experiment on the data real users depend on. The most cited cautionary tale is from July 2025, when Replit’s AI agent deleted a company’s production database despite instructions to freeze changes. Replit’s response included separating development and production databases for apps on its platform (The Register).

Two-minute check: does your AI tool or agent have the credentials for your live database? If yes, take them away and give it a test database instead.

7. Spending limits

Usage-billed services — AI models, builder credits, cloud hosting, databases — can bill faster than you expect. In builders that meter usage, bigger projects cost more per message because the AI reads more of the project each time (Bolt). Organisations feel this too: in Stack Overflow’s 2026 survey, 38% of respondents said their organisation sets AI usage limits (Stack Overflow).

Set a hard cap or a budget alert on every service with a credit card attached, before launch rather than after the first surprise bill.

8. Backups and an exit

Two questions to answer before real users arrive: if the data disappeared today, could you restore it? And if the platform shut down or tripled its prices, could you take your code and data elsewhere?

Essential	In an app builder	In a coding editor or agent
Version control	Connect GitHub sync if offered; use built-in history or restore points	A git repository; commit after every working change
Secrets	The platform's secrets or environment settings	Environment variables and a .env file that is never committed
Data access rules	Check the connected database's security settings (e.g. Supabase RLS)	Write and test the rules yourself; ask the agent to explain each
Sign-in	Built-in authentication	An auth provider or your framework's standard auth library
Rerunnable check	A written click-through list	Automated tests the agent must keep passing
Test vs live	Separate development and production databases, where the platform supports it	Separate environments with separate credentials
Spending limits	Plan limits and usage alerts	Budgets and alerts in each cloud and AI provider
Backups and exit	Restore points, data export, code export	Database backups; code already lives in your repo

The short checklist

• Every working version saved, and you’ve tested a rollback once.
• No secrets in code; any that ever were have been rotated.
• Every database table has access rules you can explain.
• Sign-in comes from the platform or a provider.
• A click-through list (or tests) run after every change.
• The AI tool can’t touch live data.
• Caps or alerts on every usage-billed service.
• A restore you’ve tried, and an exported copy of the code.

Next: the most common ways vibe-coded apps go wrong, with the evidence behind each.