Vibe coding security checklist before you launch.

The short answer: a vibe-coded app is not automatically unsafe, but “it works on my screen” is not enough evidence to launch it. Before real people depend on the app, check the parts that can expose data, take money, create unexpected bills or leave you unable to recover.

What does “safe to launch” mean?

It does not mean the app has no bugs. It means the important risks are understood, the most serious failures have been prevented or contained, and you know how to detect and recover from problems. The checks should cover the live system—not only the files that look tidy in your editor.

1. Confirm what is actually going live

Identify the real repository, branch, hosting project, database and third-party services used in production. A beautifully reviewed folder is irrelevant if the live website is built from a different branch or uses different settings.

Evidence to look for: the deployment source, production domain, environment names and the services connected to the live app.

2. Remove secrets from the code

API keys, database passwords, private tokens and payment secrets should not be written directly into source files or browser code. Store them in the hosting platform’s protected environment settings. If a secret has ever been committed or shared publicly, replace it rather than merely deleting the visible text.

3. Test logins and permissions separately

A login proves who someone is. Permission checks decide what that person is allowed to see or change. Test both. A normal user should not be able to reach admin data, another customer’s records or privileged actions by changing a URL or request.

4. Protect data and prove recovery

Know what personal or business data the app stores, where it is stored and who can access it. Validate important input on the server, not only in the browser. If the data matters, confirm that backups exist and practise restoring one. An untested backup is only a hope.

5. Trace the complete payment journey

For paid products, follow the path from checkout to payment confirmation, fulfilment, email and the customer receiving what they bought. Do not trust a success page alone. Confirm payment on the server and make webhook handling safe to repeat, so the same event cannot accidentally fulfil an order twice.

6. Put limits around AI usage and cost

If users can trigger an AI model, decide what each request may cost and how often it may run. Add sensible input limits, timeouts and rate limits. Record enough usage information to spot a loop, abuse or an unexpectedly expensive feature before it becomes a large bill.

7. Make third-party failures unsurprising

Email services, payment providers, databases and external APIs will occasionally be slow or unavailable. Set timeouts, handle errors clearly and avoid endless automatic retries. Important background work should be safe to retry and should not disappear silently.

8. Make failures visible

You need a way to know when the app is broken before a customer tells you. Capture server errors, failed jobs and important payment or fulfilment failures. Remove passwords, tokens and unnecessary personal data from logs.

9. Test the paths that matter most

Prioritise the journeys whose failure would harm a user or the business: signing in, changing permissions, saving important data, paying, receiving a purchase and cancelling or recovering. A large number of shallow tests is less useful than evidence that these critical paths work.

10. Prepare a rollback and response plan

Know how to return to the previous working release, disable a risky feature and contact affected users if necessary. Write down who can access the hosting, database, domain and payment accounts. Recovery should not depend on remembering a clever sequence while something is on fire.

Can an AI coding assistant do this check?

It can do a meaningful first examination when it can see the actual project and follows an evidence-led process. Ask it to trace behaviour across the code, configuration, tests and production setup; record what it can prove; and say what remains unverified. Do not accept “the code looks secure” as a release verdict.

What Ship Doctor adds

KHDS Ship Doctor turns this into a repeatable production-readiness examination for Codex. The free builder creates one starter check instruction. The £49 reusable toolkit adds four workflows, a 14-area diagnostic playbook, evidence templates, scoring and a remediation plan. Your code stays in the coding workspace where the project is already open.

Frequently asked questions

Is vibe coding safe for production?

It can be, but the creation method is not proof of safety. Test the real system, permissions, data handling, payments, monitoring and recovery before launch.

What should I check first?

Start with anything that can expose customer data, move money, grant privileged access or generate uncapped costs. Then check whether you can detect and recover from failure.

Does a production-readiness check fix the code?

The first examination should usually be read-only so evidence is not changed while it is being collected. Confirm findings, decide priorities, make controlled fixes and then verify them.