The Production-Ready Checklist: 30 Things Your Prototype Needs Before Real Users Touch It

The comprehensive pre-launch checklist for AI-built apps. 30 items across 6 categories — every one based on real failures I've seen in vibe-coded products headed for production.

30 things your AI-built prototype needs before real users touch it. Organised into 6 categories: security, authentication, payments, infrastructure, data, and user experience. Based on 100+ production launches.

A SoftwareMill experiment in late 2025 asked an AI coding tool to make a vibe-coded app production-ready. After 20+ agentic iterations, the AI declared it done. It wasn't — multiple OWASP vulnerabilities remained that the AI couldn't identify because it lacked the context to understand what production-ready actually means.

This checklist is that context. It's the 30 things I check on every build before real users touch the product. I've used it across 100+ production launches over 18 years — and every item exists because I've seen the specific failure it prevents.

The items are ordered by risk. Start at 1, work down. Items 1-18 are non-negotiable before launch. Items 19-30 are important but can follow shortly after if you're racing to market.

Security (Items 1-8)

Security failures can kill a product overnight. These items come first because nothing else matters if user data is exposed.

1. No hardcoded secrets in the codebase. Search your entire project for API keys, database passwords, and encryption secrets. Check for patterns like sk_live_, sk_test_, AKIA, and any long random strings assigned to variables named key, secret, password, or token. Every secret should be an environment variable loaded at runtime.

Why it matters: Automated bots scan public repositories for API keys and can exploit them within minutes. One founder's hardcoded AWS credentials cost them £15,000 in crypto mining charges before they noticed.

2. No secrets in Git history. Run git log --all -p and search for secrets. Even if you've removed them from current code, they persist in commit history. If found, rotate the compromised keys immediately and use git filter-branch or BFG Repo-Cleaner to purge history.

3. HTTPS enforced everywhere. Every page, every API call, every asset must use HTTPS. HTTP requests should redirect to HTTPS. Without this, all data between user and server — including passwords — is transmitted in plain text.

4. Input validation on every endpoint. Every API endpoint must validate the type, length, format, and range of every input. Send empty strings, extremely long strings, negative numbers, HTML tags, and SQL fragments to each endpoint. Any that cause errors or unexpected behaviour need validation.

5. SQL queries are parameterised. Search for any database query that concatenates user input into a query string. This is SQL injection — the most exploitable vulnerability in web applications. Use parameterised queries or an ORM for every database interaction.

6. CORS restricted to your domains. Check your CORS configuration. If Access-Control-Allow-Origin is set to *, any website can make authenticated requests to your API. Restrict it to your actual domains.

7. Content Security Policy headers set. CSP headers tell browsers which scripts, styles, and resources are allowed to load. Without them, your app is vulnerable to cross-site scripting attacks. Add CSP headers that restrict resource loading to your own domains and trusted CDNs.

8. Dependencies audited for vulnerabilities. Run npm audit or pip-audit and address any high or critical vulnerabilities. AI tools often install specific package versions with known security issues. Update before launching.

Authentication (Items 9-14)

Authentication is where AI tools fail most frequently and most dangerously.

9. All auth logic is server-side. Every authentication check — login validation, session verification, role checking — must happen on your server. If any auth logic exists in frontend JavaScript, it can be bypassed through browser developer tools. Search your frontend codebase for any references to roles, permissions, auth tokens, or access levels.

10. Passwords are properly hashed. Check your user database. Passwords must be hashed with bcrypt, argon2, or scrypt. If you can read passwords in any form (plain text, base64, MD5, SHA-1), the hashing is broken or absent.

11. Session tokens expire and can be revoked. Tokens should expire after a reasonable period (1-24 hours depending on your security requirements). Test that expired tokens are rejected. Verify that you can revoke sessions (e.g., when a user changes their password or when you detect suspicious activity).

12. Rate limiting on login attempts. Try logging in with wrong credentials 50 times in rapid succession. If every attempt proceeds without delay, lockout, or CAPTCHA, there's no brute force protection. Implement rate limiting: slow down after 5 failures, lock out after 10.

13. Password reset is secure. Reset tokens should be single-use, time-limited (15-60 minutes), and cryptographically random. After use, the token should be invalidated. The reset page should not reveal whether an email address has an account.

14. Role-based access is enforced at the API layer. If your app has admin users, navigate directly to admin URLs as a regular user. Call admin API endpoints with a regular user's token. If either succeeds, access control is broken. Every API endpoint must independently verify the caller's role.

Payments (Items 15-18)

Payment logic is where the gap between "works in testing" and "works in production" is widest.

15. Access is granted by webhooks, not client-side events. When a user pays, the app should only grant access after receiving and validating a Stripe webhook confirming payment success — not when the user clicks the Pay button, not when the frontend receives a response. This prevents free access from failed payments, card declines, and network timeouts.

16. Webhook signatures are verified. Every incoming webhook request must have its signature verified against your Stripe webhook secret. Without signature verification, anyone can send fake webhook events to your server and grant themselves free access.

17. Subscription lifecycle is handled. Test every subscription state: what happens when a payment fails? When a card expires? When a user cancels? When a subscription is past due? Each state should trigger appropriate access changes. AI tools typically only handle the happy path — successful payment grants access.

18. API keys are server-side only. Stripe secret keys (sk_live_, sk_test_) must only exist on your server. If they appear in frontend code, any user can see them in browser developer tools and make charges, issue refunds, or access your Stripe dashboard.

Infrastructure (Items 19-23)

Infrastructure is the invisible foundation. It's boring, it's essential, and AI tools almost never get it right.

19. Environment separation exists. You need at minimum two environments: development (where you build and test) and production (where real users are). Ideally three, adding staging for pre-production testing. Each environment should have its own database, its own API keys, and its own configuration. A bug in development should never touch production data.

20. Database backups are automated and tested. Verify that your database is backed up automatically (daily minimum, hourly for critical apps). Then actually test a restore — untested backups are as useful as no backups. Know how long a restore takes. When your database goes down at 2am, you don't want to be learning the process for the first time.

21. Error tracking is configured. Set up Sentry, LogRocket, or similar error tracking that captures every unhandled exception in production with full context (which user, which endpoint, what input). Without this, you discover errors through angry customer emails instead of dashboards.

22. Uptime monitoring is active. Configure an uptime service (UptimeRobot, Better Uptime, or similar) to ping your app every 1-5 minutes and alert you immediately when it goes down. Set up alerts via SMS or push notification — email alerts at 3am go unread.

23. Deployment has rollback capability. If a deployment breaks production, you need to be able to revert to the previous version in under 5 minutes. This means deployment versioning, database migration rollbacks, and a tested rollback procedure.

Data Integrity (Items 24-27)

Data integrity problems are insidious because they accumulate silently until they cause visible failures.

24. Database constraints enforce business rules. Check that your database has appropriate constraints: unique constraints on email addresses, foreign keys for relationships, NOT NULL on required fields, CHECK constraints on values that must be within ranges. If the database allows impossible data (negative prices, duplicate emails, orphaned records), the application will eventually store it.

25. Database migrations are versioned and reversible. Every schema change should be expressed as a migration file, committed to version control, and tested for both application and rollback. Without this, you can't safely update your database schema after launch — which means you can't ship any feature that requires data model changes.

26. Multi-tenant data is isolated. If your app serves multiple businesses or teams, verify that every database query is scoped to the current tenant. Log in as User A and try accessing User B's data by modifying IDs in API requests. This is the most critical check for SaaS applications — a data leakage incident can destroy customer trust permanently.

27. Timezone handling is correct. Store all timestamps in UTC in the database. Convert to the user's local timezone only for display. Test that events and schedules work correctly for users in different timezones. AI tools frequently generate code that assumes a single timezone.

User Experience (Items 28-30)

These items don't prevent security breaches, but they prevent the kind of user experience failures that make people abandon a product on first use.

28. Error messages are user-friendly. Trigger every error state you can: invalid form submission, network failure, expired session, rate limiting, server errors. Every error should show a clear, non-technical message that tells the user what happened and what to do next. No stack traces, no database errors, no raw JSON.

29. Forms handle edge cases. Test every form with: empty submissions, extremely long input, special characters in names (O'Brien, hyphenated names), email addresses with unusual but valid formats, pasting instead of typing, double-clicking the submit button. Each should either succeed or fail gracefully.

30. The app works on mobile. Test every critical flow on a mobile browser. Check that forms are usable, buttons are tappable, text is readable, and no horizontal scrolling is required. AI tools optimise for the desktop viewport they're developed in — mobile is almost always an afterthought.

How to Score Your App

Go through each item and mark it as Pass, Fail, or Not Applicable.

Items 1-18 (Security, Auth, Payments): These are non-negotiable. Every failure in this range is a launch blocker. Fix them before real users touch the product.

Items 19-23 (Infrastructure): These should be in place at launch but can be addressed within the first week if you're racing to market. The risk of launching without them is operational (downtime, data loss) rather than security-related.

Items 24-27 (Data): These become critical as your user base grows. Data integrity problems at scale are much harder to fix than data integrity problems with 10 users. Address them before you have meaningful traffic.

Items 28-30 (UX): These affect user retention rather than security. Launch without them if you must, but address them within the first two weeks — every user who bounces due to poor error handling or broken mobile views is a user you won't get back.

In my experience, AI-built prototypes typically pass 8-12 of these 30 items. The remaining 18-22 items constitute the final 10% — the gap between a demo and a product.

The Common Objection: "I'll Fix It After Launch"

I hear this every week. The logic seems sound: launch fast, get users, fix issues as they arise.

For items 19-30, this is sometimes acceptable. Launching without perfect error messages or mobile optimisation is a calculated risk with limited downside.

For items 1-18, launching unfixed is not a calculated risk. It's gambling. A security breach in week one doesn't just cost you the breached data — it costs you every user's trust, any press coverage you've earned, and potentially regulatory fines. A payment flaw that lets users bypass the paywall doesn't just lose revenue — it signals to your market that your product isn't serious.

The 30-day build process I use across every engagement front-loads items 1-18 in weeks 1-2, specifically so the product is secure and reliable from the first user. It's always faster to build it right than to fix it later — because fixing security in production means fixing security while real users are at risk.

Frequently Asked Questions

How long does it take to get from 12/30 to 30/30?

Typically 2-4 weeks of focused work. Items 1-18 take the longest because they require architectural changes (moving logic server-side, implementing webhook flows, setting up proper auth). Items 19-30 are mostly configuration and tooling setup — faster but still important.

Can AI tools help me fix these items?

For some items, yes. You can prompt Cursor or Claude Code to add input validation, set up environment variables, or configure CORS. For architectural items (moving auth server-side, implementing webhook-driven payments, database migration frameworks), AI tools can generate the code but you need to verify it's correct — which requires understanding what correct looks like.

Do I need all 30 items for an internal tool?

If the tool handles sensitive data or connects to production systems, yes. Internal tools have caused some of the worst security breaches in history because they were built quickly without security review. If the tool only handles non-sensitive data and runs on an isolated network, items 3, 15-18, and 22 may be less critical.

What's the cheapest way to get help with this?

A Discovery Sprint (£5,000) includes a full technical assessment against this checklist plus a plan for addressing every failure. For founders who want to fix things themselves, the sprint gives you an accurate map of what needs doing and the priority order. For founders who want hands-off, the sprint is the first step toward a production build.

Should I use this checklist for every update, or just the initial launch?

Both. Run items 1-8 (security) after every significant update — AI tools can introduce new vulnerabilities with every code generation. Run the full 30-item checklist before launch and quarterly thereafter. Make it part of your deployment process, not a one-off exercise.