Your Team Vibe-Coded an App - What Can Break Before Real Users or Data

Fast builds are useful until the first real account, the first real customer record, or the first URL on the public internet exposes a gap you never modelled. Vibe coding (exploratory, assistant-heavy development) often optimises for “it runs here” - not for ownership, abuse, or the next six months. This note is for operators and founders, not for perfectionism: it is the list of things that most often hurt when the demo becomes the system.

If you are still choosing how to build, see vibe coding vs spec-first delivery. Here we assume the build exists and you are about to add people or production data.

Identity, access, and admin surfaces

• Weak or missing authentication - shared passwords, “admin” routes without real checks, JWTs in localStorage with no expiry story.
• Everyone is an admin - one role for the whole company, or debug flags left on that bypass checks.
• No audit trail - you cannot answer “who changed this record” after finance asks.

Before you widen access: decide who may log in, what each role may do, and how you revoke access when someone leaves. If that is not implemented, you do not have an internal product yet - you have a shared prototype.

Data validation and abuse, not only “happy path”

Generator-assisted code often covers the demo inputs. Real users and integrations send empty strings, huge payloads, duplicates, wrong encodings, and malicious strings.

• Server-side validation still matters - the browser is not a security boundary.
• Ownership checks on every sensitive read/update (“can this user_id see order_id?”) - not only on the list page you tested.
• Rate limiting on login, password reset, and public APIs - cheap bots will find open endpoints.

Skipping this shows up as corrupted data, silent cross-customer leaks, or a Monday morning Support, something’s wrong message you cannot trace.

Secrets, config, and environment drift

Typical cracks:

• API keys in the repo, in screenshots, or in client-side bundles.
• .env copied from a tutorial; production still points at a dev database or test payment mode.
• No separation between staging and production secrets - one leaked Slack paste burns both.

Treat secrets as runtime config (host platform env vars, secret manager, or your host’s equivalent), rotate anything that has ever lived in chat or email, and verify which URL and which database production actually uses - not only which one you think it uses.

Dependencies and “works until it doesn’t”

AI-assisted projects often accumulate dependencies faster than anyone tracks them. That means:

• Unpinned or very broad version ranges - tomorrow’s install is not today’s install.
• Abandoned or duplicated packages - two libraries doing the same job, one never updated.
• Known CVEs - run your platform’s audit (npm audit, composer audit, etc.) and fix or replace; “we’ll do it later” is how small tools become liability.

You do not need a security team - you need one explicit upgrade cadence (monthly or quarterly) before you are under incident pressure.

Errors, logging, and operability

Production without structured logging and error reporting is a black box.

• Swallowed errors - failed jobs that return 200 or generic “Something went wrong.”
• No correlation id - three services chat to each other and nobody can tie a user report to a request trail.
• Nobody subscribed to alerts - the first downtime is discovered by a customer.

Minimum bar: centralised logs or an error service, alert on 5xx spikes, and a runbook (even a one-pager: where it runs, env vars, how to redeploy, who to call).

Performance and concurrency under real load

Laptops hide N+1 queries, unbounded lists, and synchronous chains that fine for one user. Real traffic adds concurrent writes, locks, and quotas on third-party APIs.

The classic failure is not “we need a bigger server on day one”—it is two customers doing the same operation at once and discovering a race nobody hit in demo. Do at least one controlled load test or a staging rehearsal with realistic volume before you market the tool. If you have never watched the database under parallel requests, assume it will surprise you.

Laptop vs server: parity and deployment

• “It works on my machine” often means wrong Node version, local-only file paths, or CORS opened wide for dev and never tightened.
• No repeatable deploy - only one person knows the click path to ship; they go on holiday and releases stop.
• No rollback - first bad release is a scramble.

You want documented deploy steps, same major versions in CI and production, and ideally infrastructure as code or host-native config so the environment is rebuildable.

Checklist before you add real users or regulated data

1. Auth and roles match how your organisation actually works; leavers can be disabled in minutes.
2. Secrets only in managed config; nothing sensitive in the client or repo history you rely on.
3. Production data store and payment mode verified end-to-end with a small internal cohort first.
4. Errors and logs visible to someone who will answer the phone.
5. Backups and restore tested once - not assumed.

If several of these are “we’ll do that after launch,” you are not launching a product - you are expanding the blast radius of a demo. That is fine for a throwaway experiment; it is expensive for customer PII, money, or regulatory exposure. When in doubt, buy a short hardening or deploy engagement; scoping “make it safe” is usually cheaper than cleaning up after a breach or rebuild.

---

Frequently asked questions

What does “vibe-coded” mean here?

Building quickly with exploratory, often AI-assisted coding - great for learning shape, risky if nobody translates the demo into operable software.

What usually breaks first under real use?

Access control, data handling at the edges, and environment mistakes (wrong DB, exposed keys) - before “we need a faster framework.”

Do we need automated tests before launch?

Some automated checks (even a thin suite around auth and money paths) beat none. Manual test scripts for critical flows are a minimum if you have no CI yet.

How is this different from normal software risks?

The same classes of risk exist; vibe-heavy builds often compress design time and skip explicit review, so problems surface later and faster at go-live.

When should we get outside help?

When the app will hold customer data, payments, or health or personal information, or when nobody on staff owns security, deploys, and on-call - bring help before wide rollout.