Your AI has just absorbed its fourth revision request of the evening — a dashboard tweak, a CSV export, renamed plans — and it answers with the sentence every AI-assisted builder knows: your app is ready to deploy. Half the time, that sentence is true. The build compiles, the preview renders, the feature does what you asked. The other half of the time, the app that ran perfectly on your laptop meets production and falls over on contact: an environment variable that never existed outside your machine, a database URL still pointed at localhost, a checkout flow that has never once seen a declined card. That other half is why this checklist exists.
Key Facts
Why "It Works on My Machine" Is a Different Claim Than "It Works in Production": Every failed first deploy traces back to the same gap: your development environment and your production environment are different systems that happen to run the same code.
Domain 1: Config and Secrets: Most first-deploy failures are configuration failures: the code is fine, the app just cannot find the pieces it needs.
Domain 2: Data: AI-built apps often reach production without ever being treated as data-bearing systems.
Domain 3: Money Paths: A broken feature costs you a user; a broken checkout costs you a user who was actively trying to give you money.
To be clear about where this article stands: building with AI is a legitimate way to ship software. You describe what you want, the model implements it, you steer — and a growing share of real products now launch exactly this way. What AI changes is not the legitimacy of the work but its shape. Writing code got cheap, so the bottleneck moved to everything around the code, and the part AI cannot do for you is verification. A model cannot click through your signup flow as a brand-new user, cannot know which screen matters most to your business, and cannot accept the risk of pointing real customers at the result. Verification is your half of the partnership — the checklist below is that half, made finite.
This vibe coding pre-deploy checklist covers 15 checks in five domains: config and secrets, data, money paths, behavior, and ops. Each item says what to check and, in one line, why it matters. Run end to end it takes under an hour the first time and about fifteen minutes once the app is past its first few deploys. Fail an item, fix it, rerun — a checklist you half-complete is not a checklist, it is a story you tell yourself.
Why "It Works on My Machine" Is a Different Claim Than "It Works in Production"
Every failed first deploy traces back to the same gap: your development environment and your production environment are different systems that happen to run the same code. The AI built the app against the environment it could see — your laptop — so "it works" is a statement about your laptop. Production differs in four structural ways, and each has ended more launches than any bug:
Local assumption
Production reality
What breaks
Env vars live in .env or your shell
The deploy environment starts empty
App boots with missing config, or crashes on first read
Data is SQLite, in-memory, or a JSON file
A real database over a network connection
Queries, types, and concurrency behave differently
localhost is the app, the database, and the API
localhost is the container, alone
Database connections, OAuth callbacks, and API calls fail
Your account has weeks of history
The first real user signs up to an empty app
Empty states, default roles, and welcome paths were never re-tested
None of these differences are visible from inside your editor. The code is identical in both places; what changes is the world around the code — which is why "I tested it and it works," honestly meant, coexists so comfortably with "it broke the moment a stranger used it."
Two rules govern what follows: every check happens against the deployed URL and the deploy environment, never your laptop — once a deploy exists, the deployed app is the only witness that counts — and the list runs top to bottom, fixing and rerunning until each item passes. Half a checklist produces exactly the false confidence the whole one exists to remove.
Domain 1: Config and Secrets
Most first-deploy failures are configuration failures: the code is fine, the app just cannot find the pieces it needs.
1. Every environment variable the app reads exists in the deploy environment
Ask your AI to list every environment variable the code reads — process.env in Node, os.environ in Python, or whatever your stack uses — then compare that list, name by name, against the variables configured in your deploy settings, watching for near-matches like DATABASE_URL versus DATABASE_DB_URL, which pass a glance and fail a deploy. Why it matters: the single most common cause of a dead first deploy is a variable that existed only on your laptop.
2. No secret lives in your code or chat history — rotate anything that leaked
Search the repository and its git history for anything credential-shaped: API keys, tokens, connection strings with passwords. Then extend the same audit to your AI chats — pasting an error containing a live key into a prompt is a normal accident while vibe coding, and chat history should be treated like a public paste site. Rotate anything that leaked before launch. Why it matters: leaked credentials are found by automated scanners within hours, and you cannot unsend a paste.
3. The database URL points at the production database, not localhost
Print the exact connection string the deployed app will read — password masked — and confirm the host is your production database: not localhost, not 127.0.0.1, not your dev machine. Why it matters: scaffolds default to local databases, and inside a deployed container, localhost means the container itself, which has no database on it — so the app dies on its first real query.
Domain 2: Data
AI-built apps often reach production without ever being treated as data-bearing systems. These checks fix that.
4. Migrations have been applied to an empty database AND a copy of realistic data
Run your full migration set twice: once against a brand-new empty database — the fresh-install path — and once against a copy of realistic, production-shaped data — the upgrade path. Both must succeed. Why it matters: production is always both a fresh install for someone and an upgrade of real data for someone else — a migration that has only met your dev data has verified neither.
5. Seed and test data is removed or clearly flagged
Look for the demo residue AI scaffolds love: sample users, test products, "Test Company," fake invoices, lorem ipsum. Delete it, or flag it so clearly no one could mistake it for real. Why it matters: a customer who finds another customer named Test User in your app does not conclude "seed data" — they conclude you lost their data, or someone else's.
6. First signup works from a completely fresh user
In a clean browser profile, sign up as a brand-new user on the deployed URL and click through everything a first-timer sees: welcome email, empty dashboard, default settings. Why it matters: your account predates the current schema and is coated in cached history; the first real user starts from absolute zero and hits empty states you have not seen in months.
Domain 3: Money Paths
A broken feature costs you a user; a broken checkout costs you a user who was actively trying to give you money.
7. The signup-to-paid flow has been tested in the provider's test mode
Using your payment provider's test-mode cards, walk the full path on the deployed URL: signup, upgrade, payment, receipt, and the paid state the user should land in. Why it matters: a checkout that has never been completed once will not complete itself the first time a real card arrives — and test mode exists precisely so you never have to learn that with a live sale.
8. Webhook endpoints are reachable and verified
Confirm your payment provider can reach your webhook URL from the public internet, that your app verifies the provider's signature, and that a test event arrives and does its job — flipping the account to paid, sending the receipt. Why it matters: payments confirm asynchronously, so a dead webhook means paying customers who look unpaid, or the reverse — and it fails silently, by design.
9. The failed-payment path does not crash the app
Deliberately use a test card that declines and watch what happens. The correct outcome is boring: a clear message, a chance to retry, an account that still works. Why it matters: declines are a normal Tuesday, not an exception — and every customer whose card declines and then meets a crash page is a sale you lost while they were still trying to pay.
Domain 4: Behavior
This is the domain AI genuinely cannot check for you, because "works" here includes how the app feels. Three checks, all clicked by you, all on the deployed URL.
10. The three most important screens have been clicked through on the deployed URL
Decide which three screens your product lives or dies by — usually signup, the core action, and billing — then use them on the deployed URL, not localhost, and watch for anything off. Why it matters: the deployed build differs from your machine in environment, build mode, and base URLs; localhost results stop being evidence the moment you deploy.
11. Error states have been visited on purpose
Visit a URL that does not exist, submit deliberately bad input, and if you can, point the app at an unavailable API. Every error should be boring: a clear message and a way back. Why it matters: AI-built apps are optimized relentlessly for the happy path, and error states are where trust actually dies — because that is where the user is already having a bad day.
12. File uploads and background jobs have each been exercised once
Upload a real file through the deployed app, and trigger whatever runs in the background — an email send, a report, a scheduled job — once each, confirming both actually happened. Why it matters: uploads depend on size limits, storage config, and disk that only exist in production, and background jobs depend on workers that may not be running at all until you look.
Domain 5: Ops
The last three checks are for the version of you that exists at 11 p.m. on a bad night. They take minutes now and buy you hours then.
13. A health endpoint exists and returns fast
Your app should expose a simple health endpoint — commonly /healthz or /health — that returns a quick success response without touching heavy dependencies. Load it on the deployed URL and check what comes back. Why it matters: health checks are how platforms, and you, tell "running" from "sitting there" — and releases gated on health are only as good as the endpoint they gate on.
14. You know your rollback story before you need it
Answer in one sentence, now: how do I get back to the last working version? If the answer involves research, do the research now — find the rollback control on your platform and learn what it does. Why it matters: your second deploy, not your first, is when this matters, and rollback you have to figure out mid-incident is not a plan; it is a hope.
15. You can read the logs of the running app before you need to
Find where your deployed app's logs stream — a platform dashboard, a CLI — and confirm you can see today's output, including the lines your app just wrote during checks 10 through 12. Why it matters: the first real error report arrives at the worst possible moment, and knowing where the logs live turns a panic into a lookup.
The Vibe Coding Pre-Deploy Checklist: All 15 in One List
For the second and every later run, here is the whole thing compact:
- Every environment variable the app reads exists in the deploy environment.
- No secret sits in code, git history, or chat logs — anything that leaked is rotated.
- The database URL points at the production database, not localhost.
- Migrations succeed on an empty database and on a copy of realistic data.
- Seed and test data is removed or clearly flagged.
- Signup works for a completely fresh user on the deployed URL.
- The signup-to-paid flow passed end to end in the payment provider's test mode.
- Webhook endpoints are publicly reachable, signature-verified, and observed firing.
- A declined card produces a calm retry, not a crash.
- The three make-or-break screens were clicked through on the deployed URL.
- A 404, bad input, and an unavailable API all produced boring, human error states.
- One real file upload and one background job each ran successfully.
- The health endpoint returns a fast success on the deployed URL.
- The rollback path can be stated in one sentence.
- Live logs were found and read before anything went wrong.
What AI Can Check for You — and What Only You Can
The checklist divides cleanly in half. Hand this list to your AI, and it can genuinely do the mechanical half for you:
- Grep the codebase for localhost, 127.0.0.1, and hardcoded hosts (item 3).
- List every environment variable the code reads, and diff it against your deploy config (item 1).
- Scan git history for credential-shaped strings (item 2).
- Generate a project-specific version of this checklist, with your actual routes, screens, and variable names filled in.
The other half has no delegation path, on any toolchain:
- Clicking the flows as a first-time user (items 6, 10, and 11).
- Judging whether an empty state feels welcoming or broken.
- Deciding that money passing in test mode means real money is welcome (item 7).
- Accepting the ship decision itself.
AI can produce the evidence; only you can accept the risk. That is not a limitation of the tools — it is the definition of being the owner. The founders who ship AI-built code well are not the ones who found a way to skip verification; they made verification fast enough to actually do.
The Checklist in Action: Catching the Localhost Database URL
(Illustrative example — the details are fictional.)
A founder is two days from showing an AI-built client portal to its first ten users. They run the checklist top to bottom on a fresh deploy; items 1 and 2 pass in minutes. At item 3, they ask the AI to print the exact connection string the deployed environment will read, with the password masked:
DATABASE_URL=postgresql://portal_app:REDACTED@localhost:5432/portal
Host: localhost. The value had been in the project's configuration since its third prompt — the model set up a local database to build against, and nothing in the build process ever needed to change it, because on the laptop, localhost was the database. The deployed app would have booted, passed any health check that did not touch the database, and failed on the first real query in front of the first real user.
The fix took four minutes: create the production database, set DATABASE_URL in the deploy environment's variable settings, redeploy, rerun item 6 as a fresh user. Total cost of the catch: under ten minutes. Cost of not catching it: a failed first impression in front of the exact people the launch was meant to impress. Nothing about that founder's building method was the problem — the checklist simply moved the failure from launch day to a Tuesday afternoon, where it cost nothing.
Where a Deployment Platform Fits In
Most of this checklist is platform-independent — the clicking is yours on any host. But several items get materially easier on a platform built for exactly this kind of deploy. Deployxa is one option sized for AI-built applications: it deploys Git repositories or local projects as containerized applications with automatic framework and runtime detection, so the app you built with prompts deploys the same way a hand-written one would — no Dockerfile configuration for supported stacks. The mechanics are documented in the Deployxa docs.
The checklist maps onto the platform in specific places. Environment variables are configured per deployment, which is where items 1 and 3 get fixed and stay fixed — the value lives in the deploy environment, not in a file you can accidentally commit. Releases are health-gated, blue/green style: the new version is deployed to a standby slot, verified by health checks, and only then receives traffic, while the prior healthy release stays warm for a short rollback window — during which rollback can be sub-second. Item 14 becomes a control instead of a research project; item 13 becomes the gate the release itself depends on. Per-deployment logs make item 15 a click, and AI-assisted build repair can analyze a failed build and may apply bounded fixes before retrying — bounded meaning exactly what it says: not guaranteed, and never a substitute for your review. The AI layer is described on the intelligence overview.
The honest limits: a deployment platform gates the release and hands you logs, health checks, and rollback. It cannot click through your signup flow as a fresh user, cannot judge whether your seed data is really gone, and cannot accept the ship decision. Items 6, 10, 11, and the final go/no-go stay human on every platform, including this one.
Run It on a Preview First
Do not make this checklist's first run a live event with customers watching. This week, take the AI-built app you are closest to shipping and deploy it to a preview or non-production URL — a non-production project on Deployxa works well and leaves your production system untouched. Run all 15 checks there, top to bottom. Fix what fails — something will, and that is the checklist working — then rerun the failed items. When the whole list passes on the preview, run it once more against production and ship. An hour of verification, zero customer risk, and you walk into launch holding evidence instead of an AI's assurance.