← Scare a Vibecoder

The vibe coding launch checklist

Every scare on Scare a Vibecoder ends with the real thing to check. Here are all 84 in one place, grouped by what they protect. Go through it before you launch an app you built with AI, and again whenever the AI has been busy.

Security

Who can see what, and who can change it. Check these before strangers do.

  • Decide roles on the server. Never trust a role, price or user id that the browser sends you.
  • Use an auth provider, or at least hash passwords with bcrypt or argon2. Ask the AI to show you, not tell you.
  • For every API route, check that the logged-in user owns the record they're asking for. Changing an id in the URL should never work.
  • Rate-limit signups, add bot protection, and don't send email to addresses that haven't been verified.
  • Turn on automated dependency updates for every repo, and archive the apps you no longer run.
  • Remove debug logs before you deploy, and never send the browser data the current user isn't allowed to see.
  • Before installing a package the AI suggests, check that it exists, is widely used and is the one you meant.
  • Put real login checks on admin pages. A secret URL isn't security; search engines and bots find them.
  • Password resets must go through a one-time link sent to the account's email. Never accept a new password for just an email address.
  • When you shut an app down, delete its DNS records too, or someone else can claim the subdomain.
  • Treat AI output like code from a stranger: run a license and similarity scan before it ships.
  • Any cache in front of private data must include who's asking in its key. Log in as two test customers and compare what each one sees.

API keys and secrets

Bots find leaked keys within minutes, and the bill follows soon after.

  • Keep keys in .env, add .env to .gitignore, set a hard spending limit, and rotate any key that was ever committed. Bots find leaked keys within minutes.
  • Open yourdomain/.env and yourdomain/.git/config in a browser. Both should 404. Secrets belong in your host's environment settings, never in served files.
  • One key per app, each with its own spend limit. Then one leak only takes down one app.
  • Crop or blur secrets before posting screenshots, and rotate any key that has ever been on screen in public.
  • Never ship tokens to the browser, and use fine-grained tokens that only reach one repo each.

Payments

Where a bug costs real money, fast. Try every one of these in test mode first.

  • Give every coupon a redemption limit and an expiry date, and calculate checkout totals on the server.
  • Test your payment webhook end to end in test mode, log failures, and get alerted when it errors.
  • Most payment APIs take amounts in cents. Run a full purchase in test mode and check the amount before launch.
  • Never let a support bot change plans, prices or refunds. Give it read-only access and hand money questions to a person.
  • Add bot protection and rate limits to checkout, and turn on your payment provider's fraud rules.
  • Retried payments need an idempotency key, so the same charge can never go through twice. Test it by forcing a timeout.

Your database

One table without the right rules can hand all your users' data to anyone who asks.

  • If your frontend talks to the database directly, turn on row-level security for every table and test it with the public key.
  • Know where personal data lives in each app, and how to export and delete it for one user.
  • Give each app its own database, or at least its own schema and credentials, so one mistake stays in one app.

Backups

One day the AI will delete something. These make sure you can get it back.

  • Commit to git before every AI session. git init takes two seconds; rebuilding from memory takes a weekend.
  • Use separate dev and prod databases, never give the agent prod credentials, and restore a backup once to prove it works.
  • Turn on automatic database backups, and read any delete or drop command before you let it run.

Costs and AI bills

Usage-based bills grow overnight. Set the limits before you need them.

  • Set billing alerts and spend caps on every cloud and AI account today, before you need them.
  • Measure AI cost per user, cap usage per plan, and cache repeated requests before you start growing.
  • Shut down apps with no users, and set a spending alert on every account you keep.
  • Enforce plan limits on the server and cap usage per user, especially on the free plan.
  • Save a version before every big AI change so you can roll back for free, and check your credits before starting a long task.
  • Know your AI cost per user, keep it well under a third of your price, and make switching models a config change rather than a rewrite.
  • Check your usage before starting a new build, and keep enough of your limit in reserve to fix the apps that are already live.
  • Set a monthly budget for your AI tools, look at your own usage weekly, and be open with your team about how you work.

Running it in production

The boring parts that keep an app online: domains, deploys, emails and free trials.

  • Commit your lockfile, write down your Node version, and keep a known-good commit you can always go back to.
  • Turn on auto-renew, keep the card current, and keep one list of every domain and service you own.
  • Keep a one-page README for every project: what it does, where it runs, what it costs.
  • List every service each app uses, and which ones pause or delete data on free tiers.
  • Run migrations against a copy of production data first, and read every lock and index change the AI writes before it touches a busy table.
  • Understand what you ship well enough to debug it alone at 3am, and make sure you can roll back in one click.
  • Test emails against a separate test list or test mode. Never point a test at your real customer list.
  • List every service you're on a trial for and when it ends, and put a reminder in your calendar a week before.
  • Have a person read your terms and privacy policy before launch. AI-written legal pages can promise things you never meant.
  • Load-test before launch, use connection pooling for your database, and have a simple status page ready.
  • Name projects clearly, and check which project your folder is linked to before every deploy.
  • Send each app's email from its own domain or subdomain, so one app's reputation can't sink the rest.
  • Move anything that earns money to real hosting with backups and monitoring.

Getting users

Shipping is half of it. These are about finding the people who need what you built.

  • Find where people with this problem already hang out, answer a few of their questions, then share your link there. Ten people who need it beat a hundred likes.
  • Talk to ten potential users before building the next feature. Ten conversations beat ten features.
  • Your code was never the moat; getting it in front of people is. Before starting app #13, spend a week telling the right people about one you already have.
  • Building was the easy part. Before writing more code, talk to ten people who have the problem and ask how they solve it today.
  • Views aren't users. Put one plain sentence at the top of your page saying who it's for and what it does, then ask five strangers to explain it back to you.
  • Email five people who signed up and left, and ask what they hoped it would do. Their answers are your to-do list.
  • Finish this sentence before you share again: “It helps [specific person] do [one task].” If you can't, nobody else can either.
  • Stop adding features for a week. Show the app to ten people who might use it, and only build what at least three of them ask for.
  • Don't wait for search to find you. Go where your users already ask for help, answer their questions, and mention your app only where it truly fits.
  • Launch day only works if people already know you. Spend the month before talking to future users where they hang out, then launch to them.
  • Ask for money early. A small pre-order tells you more than a hundred people saying “I'd use this”.
  • Watch what new customers do in their first week. If they don't get value by day three, fix that before you pay for any more traffic.
  • Decide who will pay before you market. Then go where those people are, not where signups are easiest.
  • Don't buy traffic until people who find you for free actually pay. Ads make a working funnel bigger; they can't create one.
  • Pick the one app with any sign of life and spend 30 days telling the right people about it before you build anything new.
  • Friends aren't a market. Find strangers who have the problem and launch where they already are.
  • Before the next build, find five people with the problem and get one of them to say they'd pay. Then build.
  • Before you shut anything down, check which app people actually come back to, and put your next month there.
  • Rewrite the top line of your landing page in your users' own words: who it's for and the one thing it does. Generic AI copy convinces nobody.
  • Before building for colleagues, sit with three of them for an hour and watch how they do the job today. Build for what you see.
  • Write the README for one specific person with one specific problem, then share it where that person already asks questions.
  • Developers rarely pay for tools. Find who owns the budget, and ask for a paid pilot before you build more.
  • Before building a feature, ask the people who requested it to show you how they'd use it this week. If they can't, don't build it yet.
  • A waitlist signup is a maybe. Ask for a small pre-payment early to learn who really wants it.

Staying in control of the code

The AI writes fast. These keep you able to explain, test and fix what it wrote.

  • Read every line the AI writes before you commit it. Your name is on it.
  • Search your codebase for “simplified” and “in production”. Then add a test for currency rounding.
  • If you can't explain a line, rewrite it until you can. Juniors notice.
  • Using AI isn't the problem. Hiding it is. Be open about how you work.
  • Have a fallback: a second provider, a local model, or the skills to finish without one.
  • Read the full diff before you open a PR, and keep agent tasks small enough that you could have made the change yourself.
  • Keep every project in a state you could hand over: a README, a sane structure and documented setup.
  • Run the code path before you push. AI happily invents APIs that look completely real.
  • Only present work you can explain, and rehearse the Q&A without notes.
  • Read the tests the AI writes. Break the code on purpose and make sure at least one test fails.

Each of these started as a scare

Tell us what kind of vibecoder you are, and find out which one would get you.

Scare me →