✳︎ MY AI GUIDE
The 42-Point Vibe Coding Checklist
Everything worth checking before you ship an AI-built app, from frontend and auth to GDPR and paying customers. No jargon, no assumption you can code.
Tick them off
42 checks, 9 categories
Tap any item to check it off. When you're done, copy the whole list and hand it to your AI coding tool to grade your own codebase.
0/42
Frontend5 items
1.No secret keys in your client code.
If a key can be read from your live site's dev tools, it's public. Anything starting NEXT_PUBLIC_ (or your framework's equivalent) is visible to every visitor by design, so only put values there you'd be fine posting publicly.
2.Responsive tested on at least 3 real screen sizes.
Phone, tablet, laptop, not just your own monitor. Most traffic on most apps is mobile.
3.Forms validate before they send anything.
A required field left blank, or an email typed wrong, should be caught on the page, not silently fail on the server.
4.Real error states, not a blank screen.
If something fails, the user should see a message, not a frozen page with no explanation.
5.Loading states on every action that takes more than a second.
A button that does nothing visible while it's working gets clicked five more times.
Backend / API5 items
6.Every route checks WHO is calling it, not just THAT someone is logged in.
Being logged in proves you're a user. It doesn't prove you're the right user. Every route touching a specific person's data needs to check the ID matches, not just the login.
7.Rate limiting on public or expensive routes.
Anything that costs you money per call, or anything a stranger could hit repeatedly, needs a cap on how often it can be called.
8.Validate on the server too, never trust the client alone.
Frontend validation is for the user's convenience. Anyone can bypass it entirely and call your API directly, so the real check has to happen server-side.
9.Errors don't leak internal details.
A failed request should tell the user something went wrong, not print your database structure or file paths in the response.
10.Destructive actions require an ownership check.
Delete, edit, cancel, refund, anything that changes or removes something, needs to confirm the person calling it actually owns the thing being changed.
Database4 items
11.Row Level Security is turned on for every table holding user data.
Without it, a misconfigured API can return every row in a table instead of just the caller's own rows. This is the single most common vibe-coding data leak.
12.Every user-owned table has a user_id column and a policy tied to it.
RLS only works if there's something to check the row against. A table with no owner column can't be locked down properly.
13.Backups are actually running, and you've actually tested restoring one.
A backup nobody has ever restored is a backup you don't actually have.
14.Sensitive fields are hashed or encrypted, never stored as plain text.
Passwords, tokens, and anything similarly sensitive should never be readable directly in the database, even by you.
Auth / Security5 items
15.OAuth redirect URLs are allow-listed, not left open.
If your login flow accepts any redirect URL, an attacker can send a real login link that redirects the session somewhere they control.
16.Sessions and tokens expire, and can be revoked.
A login that never expires means a stolen session works forever. You should be able to force a logout everywhere if something goes wrong.
17.Authentication runs through a real, established provider, never hand-rolled.
Auth is one of the few places 'AI wrote it from scratch' is genuinely risky. Use Clerk, Auth0, Supabase Auth, or similar, not custom password logic.
18.Two-factor authentication is available for admin or high-privilege accounts.
At minimum, whoever can access everything should have more than a password protecting that access.
19.Environment variables are actually confirmed out of git, not assumed.
Check your repository history, not just your current .gitignore. A key committed once and later 'removed' is still sitting in the git history.
Hosting / Deployment4 items
20.HTTPS is enforced, with no plain HTTP fallback.
Modern hosts do this by default, but it's worth confirming rather than assuming.
21.Staging and production never share the same database.
Testing against real user data, or accidentally wiping production data from a 'test', is a completely avoidable disaster.
22.Deploy logs don't print secrets.
Check your build/deploy output for anything that logs full environment variables or request bodies during setup.
23.A real person reviews what's actually public before going live.
AI-scaffolded projects sometimes expose an admin route, a debug page, or a test endpoint nobody meant to ship. One pass through your own site as a stranger catches most of these.
Payments3 items
24.Your payment provider handles raw card data, your server never touches it.
Stripe, Lemon Squeezy, and similar handle this correctly by default if you use their hosted checkout or elements. Never build a form that sends raw card numbers to your own server.
25.Webhook endpoints verify the signature, not just trust the payload.
Anyone can send a fake 'payment successful' request to an unverified webhook. Signature verification confirms it actually came from your payment provider.
26.The cancel and refund flow is tested end to end, not just built.
Run it once for real before a real customer needs it.
Compliance / Privacy8 items
27.Cookie consent fires before tracking scripts load, not after.
If analytics or ad scripts run before someone accepts cookies, the consent banner isn't doing its job.
28.A real privacy policy exists and matches what the app actually does.
A generated template that lists tools you don't use, or omits ones you do, is worse than having none, since it's now inaccurate on the record.
29.Data processing agreements are in place for every third-party tool that touches user data.
Your email provider, analytics tool, and hosting platform all need a real agreement covering how they handle data on your behalf.
30.Users can actually access or delete their own data.
GDPR gives every user the right to see what you hold on them and to have it deleted on request. A policy mentioning this right without a real way to exercise it doesn't meet the bar.
31.There's a real plan for a data breach, worked out before you need it.
GDPR requires notifying the relevant authority within 72 hours of discovering a breach. Knowing who to call and what to say ahead of time is the whole point.
32.Fonts and third-party scripts are self-hosted, or only load after consent.
The default way most builders load Google Fonts sends every visitor's IP address to Google before any consent banner appears. A German court has already fined a site for exactly this, when self-hosting was free and available.
33.Any AI-generated content shown to users is disclosed as AI-generated.
The EU AI Act requires this for realistic AI images, video, and audio, and for AI-written text on matters of public interest, as of 2 August 2026. It applies based on where your users are, not where your business is registered.
34.The site meets basic accessibility standards.
Keyboard navigation, real color contrast, alt text on images, and actual form labels. The European Accessibility Act has required this for new products since June 2025, and WCAG 2.1 AA is the standard that satisfies it.
Commercial / Business5 items
35.Terms of Service exist, are accessible, and actually match what the product does.
Same principle as the privacy policy: a generic template that promises features you don't have, or misses ones you do, undermines the whole document.
36.Pricing is shown clearly, with no fee that only appears at checkout.
A fee revealed at the last step is a well-known consumer protection violation in most jurisdictions that sell online, not just a bad look.
37.A real support channel exists, and someone actually reads it.
A contact form nobody reads is worse than no contact form at all, since it makes a frustrated user feel actively ignored.
38.Sales tax or VAT is handled for the countries you actually sell into.
Selling digital products to EU customers has its own VAT rules, separate from wherever your business is based. Worth checking before you have real revenue to untangle.
39.Cancelling or refunding takes one click from account settings, not a 'contact us to cancel' email.
As of 19 June 2026, EU law requires a genuine one-click cancellation button for any business selling to EU consumers, with confirmation sent automatically. A support-ticket-only cancellation flow no longer meets the bar.
Monitoring3 items
40.Error tracking is wired in before launch.
You want to find out about a broken checkout from a dashboard, not from an angry comment.
41.Uptime monitoring on the live URL.
A free check every few minutes tells you the site is down before your users do.
42.Analytics are set up before launch, not added later.
Without it, you have no way to know if anyone is actually using what you built, or where they're dropping off.
Want more guides like this?
We test the new AI tools so you don't have to, then explain them in plain English. No hype, no jargon.
Explore My AI Guide →