You developed an app with an AI assistant. It works on your computer. The screen is beautiful, the pages load, the test user manages to register and use it. Are you ready to launch it?
Probably not.
What you see on your device is 15% of what matters. The remaining 85% — security, compliance, performance, scalability, costs — is not visible until something breaks. And when it breaks, it's too late.
In this guide we give you the 12 concrete checks to do before exposing your vibe-coded app to the public. For each: what to verify, how to do it, why it matters.
1. Passwords and credentials
What to check: how user passwords are stored.
How: open the test database and search for a user. If you see the password in plain text, there's a problem. Even if you see a hash starting with md5( or sha1(, there's a problem. Passwords must be saved with a dedicated algorithm and an adjustable cost factor.
Why it matters: in case of breach (unauthorized database access), users suffer credential theft, often reused on other services. The responsibility lies with whoever left passwords vulnerable.
2. Validation of all user input
What to check: every field where a user can write something must be treated as potentially hostile.
How: search the code for every request.body, req.params, query.X. Verify there's a validation library (schema validator) checking type, length, format. For fields ending in database queries, shell commands, or rendered HTML, specific attention is needed.
Why it matters: SQL injection, command injection and XSS are 25-year-old attacks that still work when input is not validated. They are also among the first that automated bots try on new domains.
3. Rate limiting and brute-force protection
What to check: how easy it is for an attacker to try 10,000 passwords per second on your login.
How: try 50 consecutive failed logins on the same account. If you don't get blocked, rate limiting is missing. For public authentication services, temporary blocking after N attempts is a minimum.
Why it matters: without rate limiting, any account can be attacked en masse. With accounts tied to paid plans, it can lead to misuse or fraud.
4. Privacy policy and cookie banner
What to check: the privacy policy exists, is linked from the homepage, truly describes what the site does with data. The cookie banner blocks trackers before explicit consent.
How: open the site from a fresh session. Verify that before accepting the banner, no calls to third-party domains (analytics, ads, maps) start. The privacy policy must be consistent with what the site actually collects.
Why it matters: GDPR always applies, and European data protection authorities regularly fine Italian sites using non-compliant cookie banners. Penalties start from a few thousand euros for SMEs and grow quickly.
5. Encryption of data at rest
What to check: sensitive data in the database is encrypted or in plain text.
How: depends on the data type. Phone numbers, addresses, payment data, private conversation texts should be protected at least with column-level encryption (for the most sensitive fields) and/or disk-level encryption.
Why it matters: if the database is exfiltrated, plain-text data = users compromised directly. Encrypted data = time to react and mitigate.
6. Dependencies and known CVEs
What to check: every third-party library used by your app is up-to-date and free from known vulnerabilities.
How: package managers have built-in audit commands showing known vulnerabilities of current dependencies. The result must be "0 high/critical vulnerabilities". If there are any, they must be updated or replaced.
Why it matters: a vulnerability in a dependency is an open door in your software, even if the code you wrote is perfect. Automated bots scan sites to identify known vulnerable versions.
7. Error configuration and logging
What to check: what the user sees when something goes wrong.
How: force an error in an endpoint (pass a null parameter where a valid one is needed). The response must be a generic message ("An error occurred"), not a stack trace with the server path, libraries used and — worse — SQL queries.
Why it matters: public stack traces are gifts to attackers: they reveal technology, structure, sometimes credentials. In production they should only go to internal logs.
8. Basic load testing
What to check: your app handles a realistic peak of simultaneous users for your case.
How: free tools exist that simulate traffic (e.g., 100 simultaneous users for 5 minutes). If the site dramatically slows down or crashes, the infrastructure is not sized or the code has bottlenecks.
Why it matters: launch day, the day of a press mention, the day of a viral spike: your app must hold up. A crash under load is the worst business card.
9. Backup and restore procedure
What to check: data is automatically saved elsewhere, and you know exactly how to restore it if needed.
How: set up automatic daily backups. At least once — before launch — perform a complete restore procedure on a test environment. Only this way do you know the backup is actually usable.
Why it matters: the day an employee accidentally deletes a table, or a ransomware attack blocks the database, the difference between a company and one that closes is the tested backup.
10. Monitoring and alerts
What to check: if the app breaks, someone notices before the user.
How: configure an alert system for: 500 errors (server errors), response times above threshold, backup job failures, expiring TLS certificates. Even an email alert is a starting point.
Why it matters: without monitoring, the only feedback source is user complaints. And every user who experiences an error probably won't report it: they'll change service.
11. Cloud costs under control
What to check: expected cloud spend, threshold alerts, resource sizing.
How: most cloud providers allow setting a monthly budget with automatic alerts. Verify resources (database, containers, storage) are sized for expected traffic, not over-sized for safety.
Why it matters: a vibe-coded app can easily make 10× the necessary queries per page, or keep containers active when they could turn off. Over the month it transforms into a surprising bill.
12. HTTP security headers
What to check: the site responds with the right security headers.
How: public tools exist (security header scanners) that give a grade from A+ to F. The minimum acceptable is B. At minimum, present: HSTS, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
Why it matters: some of these headers protect against specific attacks (clickjacking, MIME sniffing, script injection). They cost nothing to configure and make a concrete difference.
Summary table
| # | Check | Estimated time | Difficulty |
|---|---|---|---|
| 1 | Passwords and credentials | 30 min | Low |
| 2 | Input validation | 2-4 hours | Medium |
| 3 | Rate limiting | 1-2 hours | Medium |
| 4 | Privacy policy + cookies | 2-3 hours | Low |
| 5 | Data encryption | 4-8 hours | High |
| 6 | Dependency audit | 30 min | Low |
| 7 | Errors and logging | 1-2 hours | Low |
| 8 | Load testing | 2-4 hours | Medium |
| 9 | Backup and restore | 3-5 hours | Medium |
| 10 | Monitoring | 2-4 hours | Medium |
| 11 | Cloud costs | 1 hour | Low |
| 12 | Security headers | 30 min | Low |
Estimated total: 20-35 hours of work for a medium-complexity app, if you know what to do. If you don't, double it.
Want a complete checklist, already done, for your app?
We perform all 12 checks on your code in 5-7 working days. We deliver a report with priorities (what to fix immediately, what can wait) and — if you want — we handle remediation directly. We work from the repo you already have, no unnecessary rewrites.
Request an audit for your appThe most expensive mistake we see
The worst pattern is not "doing the checks badly". It's not doing them at all and finding out later they were missing. When a site violates GDPR, the authority's order arrives months later — and recovering by then is much more expensive.
Treating the pre-launch checklist as a natural part of the project, and not as an annoyance to do "if there's time", is the difference between a calm launch and a damage-control race.
Conclusion
Developing with AI is the most important novelty of the last 10 years in software. It allows anyone with an idea to bring it to life. But software meeting real users has always been — and will always be — a technical terrain, where execution quality matters as much as idea quality.
The 12 checks of this guide are not an exam: they are the bare minimum to not harm yourself and your users. If you do them (or have them done), you start on the right foot. If you skip them, sooner or later you pay for it.
The good news is that doing them — once — is much less burdensome than it seems.
Frequently asked questions
Related services
The services this article talks about
AI Bug Fixing
Risolviamo bug e problemi nei progetti generati con AI (ChatGPT, Claude, Cursor) o tradizionali: root-cause analysis, fix, refactor, test di regressione.
Discover the service →AI Completa end-to-end
Completiamo end-to-end il tuo progetto AI: refactor codice ChatGPT/Claude/Cursor, sicurezza, database, hosting, CI/CD, deploy e supporto continuativo.
Discover the service →