The vibe coder's
deployment checklist.
10 rules before you go live.

The single biggest source of broken vibe-coded projects is not bad AI output — it is unclear requirements. If you cannot explain in plain language what your product does, who it is for, what data it handles, and what happens when things go wrong, the AI will fill in the gaps with assumptions. Those assumptions will not match your business logic.

Before you open any AI tool: write down what the product does in one paragraph. Write down who uses it. Write down what data it stores. Write down what happens when a user's action fails. Write down what countries it operates in. If you cannot answer those questions, you are not ready to build yet.

Research the market. Research the laws. Research what competitors have built and what they got wrong. The AI cannot research your specific competitive landscape for you. The thinking that happens before the first prompt is where good products start.

The AI will not automatically include security hardening unless you ask for it. "Build me a user authentication system" and "Build me a user authentication system with bcrypt password hashing, rate limiting on login attempts, CSRF protection, input sanitisation on all fields, and parameterised queries on all database calls" produce very different code.

Every prompt involving user input, authentication, data storage, or external API calls should explicitly request security considerations. Add this to your system prompt or context when starting any project:

Cloudflare's free tier is one of the most powerful security tools available to any developer. It sits between your server and the internet, filtering malicious traffic before it reaches your code. For a vibe-coded project that may have unknown vulnerabilities, this is not optional — it is your first real defence layer.

Point your domain's nameservers to Cloudflare when you buy the domain. Do not skip this step. Then in the Cloudflare dashboard, enable these settings specifically:

A race condition happens when two operations run simultaneously and each assumes it is the only one running. The classic example: a user clicks "Buy" twice in quick succession. Your app checks the inventory, sees 1 item available, and both requests pass the check at the same time. Both orders go through. You have sold the same item twice and your stock count shows -1.

Here is a simpler one you might not think about: a user clicks a payment button twice because the page was slow to respond. Two payment requests hit your backend simultaneously. Both charge the card. You have charged your customer twice and now need to refund one — assuming you catch it.

Race conditions are extremely common in vibe-coded projects because the AI will often generate the happy path — "user clicks button, thing happens" — without automatically handling concurrent requests. The fix requires specific patterns: database-level locking, atomic operations, idempotency keys on payment requests, and UI-level button disabling after the first click.

Payment processing is not a feature. It is a discipline. PCI-DSS compliance, fraud detection, chargeback handling, refund logic, failed payment retries, webhook verification, subscription lifecycle management — these are entire fields of expertise. A vibe-coded payment system built without understanding these requirements is a liability.

The practical rule: Never store card numbers yourself. Ever. Use Stripe, PayFast, Yoco, or another PCI-compliant payment processor and let them handle the card data. Your code should never touch the raw card number — only tokens and payment intents provided by the processor.

If you are building anything beyond simple one-off payments — subscriptions, marketplaces, split payments, escrow — seriously consider partnering with a developer who has done it before, or taking a course specifically on payment systems before you direct the AI to build it. The AI will build what you describe. If you do not understand what needs to be described, the gaps will cost you.

Every country with a digital economy has privacy laws. South Africa has POPIA. The EU has GDPR. California has CCPA. Brazil has LGPD. If your product is accessible to users in those jurisdictions — and a website is accessible everywhere — those laws apply to you.

At minimum, before you launch, you need: a Privacy Policy that accurately describes what data you collect and why, a Cookie Consent mechanism if you use tracking or analytics cookies, a Terms of Service, and a Data Retention policy. These are not optional box-ticking exercises — they are legal requirements in most jurisdictions that expose you to real fines if ignored.

Cookie consent specifically: If your site uses Google Analytics, Facebook Pixel, or any third-party tracking script, you need a cookie banner that allows users to accept or reject non-essential cookies before those scripts fire. Most vibe-coded sites have analytics loaded in the `<head>` unconditionally. That is a GDPR violation for any EU visitor.

This is the most important mindset shift for any vibe coder going to production. The code runs under your domain, on your servers, with your business name attached. When it fails — and at some point it will fail — the responsibility is yours. Not Claude's, not OpenAI's, not Google's.

Double-check the plumbing means: Go through every form on your site and submit garbage data — what happens? Go through every authenticated endpoint and try accessing it without being logged in — what happens? Go through every email your system sends and verify it actually arrives with the right content. Go through every error state and confirm it shows something useful rather than a raw stack trace. Check that environment variables and API keys are not exposed in client-side code. Check that your database is not publicly accessible.

Ask the AI to audit itself. Seriously. "Review this codebase and flag any security vulnerabilities, exposed credentials, missing authentication checks, or unhandled error states." The AI that built it can also review it — and it will find things you missed.

Using a Google Images result on your commercial website is copyright infringement. Full stop. It does not matter that the image was easy to find. It does not matter that you are a small startup. Copyright holders — and more commonly, the licensing agencies that represent them — actively search for unlicensed commercial use and send invoices. Those invoices are legally enforceable.

The safe sources:

Pexels (pexels.com) — completely free for commercial use, no attribution required. High quality. Enormous library. Use this first.

Pixabay (pixabay.com) — same model as Pexels. Free for commercial use, no attribution.

Unsplash (unsplash.com) — free for commercial use, attribution appreciated but not required.

AI-generated images — ask the AI to generate a completely original image for your specific need. No copyright issues because it is a new creation. For South African and African imagery specifically, this is often the best option since stock libraries are thin on local content.

For video: Pexels also has free stock video. Pixabay does too. For anything more specific, Mixkit (mixkit.co) offers free commercial video footage.

The Google Play Store and Apple App Store review processes are effectively free quality and compliance audits. They check for: broken functionality, crash on launch, missing privacy policy, data collection without disclosure, deceptive UI patterns, intellectual property violations, and content policy violations. If your app would fail their review, those are real problems — not bureaucratic obstacles.

Even if you are building a web app rather than a mobile app, run your project through their mental checklist. Ask yourself honestly: Does this app crash or behave unexpectedly in any flow I have tested? Does it have a privacy policy that accurately describes what it collects? Does it have terms of service? Does it do what it says it does? Does it handle errors gracefully or just crash? If the answer to any of those is no — fix it before you launch, not after.

Google's Play Store policies are publicly available and more detailed than most compliance checklists you will find elsewhere. Reading the Play Store Developer Content Policy is genuinely useful even for web-only projects.

You know how your app is supposed to work. Your users — and attackers — do not. Test it as someone who is actively trying to break it.

Basic pen testing you can do yourself: Try submitting forms with script tags in text fields (`<script>alert('xss')</script>`). Try accessing `/admin` without being logged in. Try changing a URL parameter from your user ID to someone else's. Try uploading a file with a `.php` or `.exe` extension where the form expects an image. Try submitting a payment form twice in rapid succession. Try making an API request without the authentication token.

Free automated scanning: Run your live URL through Mozilla Observatory (free, checks HTTP headers and security config). Use SSL Labs to verify your HTTPS configuration. Use securityheaders.com to check your response headers.

AI-assisted pen testing: For deeper security analysis, Claude (with Anthropic CVP approval for security research contexts) can assist with identifying vulnerability patterns, reviewing authentication logic, and generating test cases for common attack vectors. Describe your architecture and ask it to identify the most likely attack surfaces. It will flag things you did not think to test.

Test the features, not just the happy path. What happens when a user enters 10,000 characters into a text field? What happens when they submit the form with JavaScript disabled? What happens when their session expires mid-flow? What happens when the external API your app depends on returns an error? These are the edge cases that produce support tickets, data corruption, and security vulnerabilities.