Production is not your laptop

While you're building, mistakes are free. Break something, ask the AI to fix it, break it differently, nobody knows. That freedom is why vibe coding works at all.

The day a stranger uses your app, the physics change. Their data is real, their Tuesday morning is real, and "oops, let me regenerate that" stops being an option. Nothing about the code changes that day — what changes is that four questions you've never had to answer suddenly have to have answers. Founders who get burned in the first months almost always get burned by one of these four, not by bad code.

Could you get the data back?

Ask yourself, honestly: if your database vanished tonight, what exactly would you do tomorrow?

We assumed we were fine, because our database provider keeps a rolling history you can rewind, like an undo slider. When we finally checked, the slider went back six hours. Any mistake discovered the next morning — a bad deletion, corrupted records, the AI "cleaning up" a table — would have been permanent. The fix took one setting and one minute: seven days. It had sat at six hours for two months because nobody had looked.

Two lessons travel. Check the number — every provider has a rewind window, and the default is chosen for their costs, not your survival. And a rewind window is not a backup: it lives inside the same account as the database, so it protects against mistakes made in the data, not against losing the account, the provider, or access itself. A real backup is a copy that lives somewhere else.

One more layer costs nothing: ask your AI to make deletion inside your app recoverable — a trash that empties after thirty days, not an erase. The best restore is the one you never need.

Could you put yesterday back?

The first question was about your data; this one is about your app. Some shipped changes turn out to be bad in ways no check catches, and the question isn't whether that happens — it's whether "put yesterday's version back" is a two-minute step you know, or a panicked hour of prompting while users hit the broken thing.

Hosting platforms make the app half easy: they keep previous versions, and rolling back is a button. The trap is the database. If a change reshapes stored data at the same time it changes the app, yesterday's app may no longer run against today's data — the undo button breaks precisely when you need it. This rule, straight from our own rules file, prevents it:

Never change the shape of stored data in the same release that stops
supporting the old shape. Add the new alongside the old first; remove the
old only in a later release, once the new version has proven stable. The
previous version of the app must always still run against the current data.

Your AI knows how to honor this. It just won't unless told, because the shortcut is faster.

Would you hear about a crash before the user tells you?

When your app breaks for someone at 9pm, one of two things happens: an error-reporting service tells you within seconds, or nothing tells you at all. There is no middle. Without the wiring, a crash leaves no trace you'll ever see — the user hits an error page, maybe tries again, usually just leaves. You find out weeks later, in an offhand "oh yeah, it wasn't working for me," multiplied by everyone who never said anything.

Error reporting is a solved problem: services exist that catch every crash and email you, with free tiers meant for apps your size, and your AI can wire one up in an afternoon. This is the single highest-value hour in this article.

Are you experimenting on real people's data?

"Just fixing it live" is how small mistakes become famous ones. You need a second copy of the app — a staging environment, pointed at fake data — where changes are tried before real users meet them. Your AI can set this up; what it can't do is supply the discipline to use it. Rule of thumb: if you're nervous while typing, you're in the wrong environment.

The readiness audit

One prompt covers all four. Run it before launch, and again whenever the honest answer to "when did I last check?" is a shrug:

I want to be ready for real users. Review this project and answer in plain
language:

1. Backups: if the database vanished right now, what would we lose, and how
   would we get it back? What's the oldest moment we can rewind to? Is any
   copy stored outside the database provider? Has a restore ever actually
   been tested?
2. Undo: if today's release turns out to be bad, list the exact steps to
   put yesterday's version back, how long they take, and whether any recent
   change to stored data would break doing so.
3. Crashes: if the app breaks for a user tonight, how do I find out before
   they tell me? If the answer is "you don't," propose an error-reporting
   setup and what it costs.
4. Environments: is there any way I'm currently testing against real users'
   data? If so, propose how to separate a staging copy from production.

Report first. Set nothing up until I've read it and said go.

None of this is over-engineering — it's the difference between a project and a service, and all four answers together cost maybe two afternoons. The code side of your company can be this systematic. So can the rest of it; that part is what Groundwork is for.