What Your Vibe Coded App Needs Before Someone Pays for It

A list went around this week of everything a vibe coded app needs before it touches a paying customer. About 150 lines. SSO, SAML, SCIM, SOC 2, HIPAA, a second region, an on call rotation, dunning emails, tracing across services. Every line is true, and the effect is that people read it and freeze.

I build a lot of small products, mostly alone, mostly with AI writing a big share of the code. I have shipped iPhone apps, Mac apps, web apps with real payments and APIs that real people hit at three in the morning. So I read that list the way I read every checklist. Which of these will actually hurt me, and which belong to a company I am not yet?

Most of the list is for a B2B company selling to enterprises. SAML exists because an IT department demands it. SOC 2 exists because a procurement team asks for it. When that customer shows up, you will have a contract and a budget, and that is a good problem.

The rest boils down to a short list. It is the difference between a bad day and the end of the product. Here it is, grouped by what goes wrong.

Data you can get back

Everyone says they have backups. Very few people have ever restored one. A backup you never restored is a file you hope works, and the day you find out is the day you need it.

Daily backups, on a schedule you did not set by hand. Most managed databases do this with one setting. Check that it is on.
One real restore. Restore last night's backup into a scratch database and count the rows. Put a reminder to do it again in six months.
Point in time recovery, if your database offers it. Someone will eventually run a delete without a where clause. It might be you, it might be the agent.
Soft deletes for anything a user cares about. Then "I deleted it by accident" becomes a support reply instead of an incident.

Money that adds up

Payment bugs are the ones customers remember. They are also the ones AI code gets subtly wrong, because the happy path works perfectly in testing.

Store money as integers. Cents or yen, never floats. 0.1 plus 0.2 is not 0.3 in floating point, and your accountant will notice.
Verify every webhook signature. A payment webhook without a signature check lets anyone mark an order as paid.
Make webhooks idempotent. Payment providers retry. The same event will arrive twice, and it must not ship two orders or grant two subscriptions.
Reconcile once a day. A tiny job that asks: who paid, and did they get what they paid for? Paid with no shipment, paid with no access, refunded with access still on. This one check catches problems that nothing else will.

Who can see what

The most common serious bug I see in AI written backends is simple. The API takes an id, loads the record and returns it, without asking whether that record belongs to the person asking. Change one number in the URL and you are reading someone else's order.

Check ownership on the server, on every route that takes an id. Then test it: log in as user A, request user B's record, expect a refusal.
Validate on the server. The form is a suggestion. Anyone can send the request without it.
Rate limit login, signup and password reset. Most frameworks have this built in. It just ships turned off.
Treat everything inside an app binary as public. An API key compiled into an iPhone or desktop app can be pulled out by anyone who downloads it. Keys live on your server. The app gets a short lived token from you.
Keep secrets out of the repo. Turn on secret scanning in your git host. It costs nothing and it catches the key the AI pasted into a config file.

Bills that cannot run away

This section is new. Five years ago a bad deploy cost you uptime. Today an AI endpoint without limits can cost you real money in one afternoon, and the invoice is how you find out.

A hard spend cap at the model provider. Not a budget alert. A cap that stops spending. Know which console actually enforces it, because many billing "budgets" only send an email.
A per user limit on your own server. The provider cap protects your bank account. The per user limit protects your other users, so one heavy account cannot burn the month for everyone.
Cost alerts that reach your phone the same day. A runaway loop should be a notification at lunch, not a line on next month's invoice.

Knowing before your users do

If your customers tell you the site is down, you found out last. Small products rarely get a second chance after the first silent outage.

Uptime checks from outside your own network. One scheduled job that hits your homepage, your API and your payment endpoint every few minutes, and messages you when one fails.
Error tracking that groups the same bug. One alert with a count, not four thousand emails.
Logs that never contain passwords, tokens or card numbers. Search your logs for the word token once. You may be surprised.

Things that expire quietly

Domains, SSL certificates, push notification certificates, signing certificates, OAuth tokens that last sixty days. None of them break loudly in advance. They just stop working one Sunday.

Make one list of everything with an expiry date, with the date next to it. Turn on auto renew for every domain you would be sad to lose. Put the rest in a calendar. This takes twenty minutes and it prevents the most embarrassing outage there is.

A way back

Rollback in one command. Before every deploy, know the exact command that puts the previous version back. When something is broken in production, roll back first and debug second.
Tests that run before anything merges. Not a full suite on day one. The three flows that make you money: sign up, pay, use the thing you paid for.
A remote switch for mobile apps. You cannot roll back an app on someone's phone. A small config endpoint that can say "this version must update" is what lets you retire a broken or insecure build.

Words that match the code

Your privacy policy, your App Store privacy labels and your terms describe what the code does. When you add analytics, a new AI provider or crash reporting, the policy changes in the same release. And if users can create an account, they need a way to delete it that actually reaches every table and every file you stored for them.

What can wait

SSO, SAML, SCIM, SOC 2, HIPAA, data residency, multiple regions, autoscaling, distributed tracing, a status page, a public API sandbox, a penetration test. All real, all useful, and all triggered by a specific customer or a specific kind of data. If you handle health records or sell to a hospital, HIPAA moves to the top on day one. If not, build them when someone asks and is ready to pay for them.

Let the AI check its own homework

The same tools that wrote the code are good at auditing it, if you ask for proof instead of reassurance. This is the prompt I use:

Audit this project against the list below. For each item, answer
done, partial or missing, and show the evidence: the file and line,
the command you ran and its output, or the setting you checked.
"It looks fine" is not evidence. If you cannot check something,
say so instead of guessing.

- backups scheduled, and the last successful restore
- money stored as integers
- webhook signatures verified, webhooks idempotent
- ownership checked on every route that takes an id
  (write a test that requests another user's record)
- server side validation and login rate limits
- no secrets in the repo or in client builds
- provider spend cap and per user limits on AI endpoints
- outside uptime check and grouped error tracking
- every domain, certificate and token with its expiry date
- rollback command for each deploy target
- tests that run before merge

Rank the gaps by what would hurt a paying customer first.
Change nothing yet.

The answer is usually humbling, and that is the point. It turns a 150 line list of fear into ten things to fix this week.

The original list ends by saying you will still need people who know what they are doing. I agree, with one change. What you need is someone who knows what to check, and who checks it. Sometimes that is a senior engineer. Sometimes it is you with a good checklist and an AI that has to show its work.