What to do when your AI-built app breaks at 2am (and you're not a developer)

You built an app without writing any code. It worked all week. Then a user messages you at 1:47am saying the signup button doesn’t do anything, and you wake up to your phone glowing on the nightstand.

If you’ve never had to fix a live app before, this moment can feel awful. You don’t read code. You don’t know what “the database” really means. You’re not sure if it’s broken-broken or just-weird, and the people who’d normally help are asleep.

Here’s a calm, ordered playbook for what to do when an AI-built app breaks and you can’t write code. Most of it is about not making things worse, which is the part nobody warns you about.

First: do not redeploy

There is a button somewhere in your AI app builder that says something like “republish”, “redeploy”, or “ship”. You are about to want to press it. Don’t, yet.

Pressing redeploy on a half-broken app can lock in the broken state, blow away whatever data debug information was sitting around, and make it harder for anyone — including the AI builder itself — to figure out what went wrong.

The first move is always to look, not to act. You haven’t even confirmed what’s broken yet.

Step 1 — Reproduce the problem yourself

Open the app in a fresh browser window — incognito or private mode is best, because it removes any old login or cache that might make things behave differently for you than for your user.

Try to do the exact thing the user reported. If they said the signup button doesn’t work, try to sign up. If they said the dashboard is blank, try to log in and view the dashboard.

You’re looking for one of three things:

It’s broken for everyone. You hit the same problem. That’s actually the easiest kind to fix because it’s consistent.
It works for you. This is the hardest scenario, because something about the user’s specific situation (their browser, their account, their data) is the problem.
It’s intermittent. It works once and breaks the next time. This is the most stressful but also the most informative — it usually means something is timing out or running out of a resource.

Write down which of the three you saw. You’ll need it when you ask for help.

Step 2 — Check the obvious external things before blaming your app

A surprising number of “my app is broken” moments are not your app. Before you spelunk into your AI builder, check:

Is the internet itself fine? Open a couple of other sites. If your wifi is flaky, your app might be fine and you might be the broken one.
Did the AI builder itself have an outage? Most AI app builders have a status page (search the product name plus “status”). If they’re having a bad night, you don’t have to figure out anything else.
Did one of your connected tools go down? If your app uses Stripe for payments, an email service for notifications, or a database service to store data, any of those can have outages. Each has its own status page. Check the ones your app depends on.

About one time in five, the answer is “it’s not actually my app”, and you can go back to sleep.

Step 3 — Look at the error message, even if it scares you

If your app shows a screen with text on it — even gibberish-looking text — read it. Take a screenshot. Especially if there’s a long string of letters and numbers (people call this a “stack trace”; it looks like alphabet soup but it’s the most useful thing you can have when asking for help).

Most AI app builders also have a place to see errors that happened recently. It might be called Logs, Activity, Errors, or Console. Open it. You don’t need to understand most of what you see — you’re looking for the most recent red text or the most recent error, and the time it happened. Time matters: an error from yesterday morning is probably not why your user couldn’t sign up just now.

Copy that error. You’re going to paste it somewhere helpful in a minute.

Step 4 — Ask the AI builder what changed

This is the move most non-technical builders underuse. Open the chat with your AI builder and say, in plain language:

“My app is broken. Users can’t sign up — the button does nothing. Here is the error from the logs: [paste it]. What changed in the last 24 hours, and what could be causing this?”

A good AI builder will tell you which recent change is most likely responsible. Sometimes you’ll recognize it immediately (“oh, I asked it to make the form look nicer yesterday and that probably broke the submit logic”). Sometimes it’ll point at something you don’t remember touching, which is also useful — it means something automatic changed, like a connected tool updating.

Do not let the AI builder start making fixes yet. You’re still in diagnosis mode. The most common way I’ve seen people make a small problem worse is by letting an AI start “fixing” things before anyone understands what’s broken.

Step 5 — Decide whether to roll back

Almost every AI app builder lets you go back to an earlier version of your app. Sometimes it’s called “history”, “versions”, “checkpoints”, or “rollback”.

If you can clearly remember an hour or a day when the app worked, going back to that version is the single most reliable move. It costs you whatever changes you made in between (which you might not even want anymore), and it gives you a working app to wake up to.

A good rule: if the broken thing is something users do every day (signup, login, payment), roll back first and fix forward later. Working-but-stale beats broken-and-current every time.

If the broken thing is a feature you added today that nobody is depending on yet, you can leave it broken until morning and fix it with a clear head.

Step 6 — If you must let the AI builder fix it

If rollback isn’t possible, or you’ve decided not to, then let the AI builder propose a fix. Two things to keep in mind while it does:

Read what it’s planning to change before approving. You won’t understand all of it, but you can spot whether it’s editing one focused thing or rewriting half the app. Small, focused changes are much safer than sweeping ones at 2am.

Test the fix in the most boring way possible. Don’t just ask “is it fixed?” and trust the answer. Actually go to the app yourself in an incognito window and do the thing that was broken. If the fix worked, the broken thing now works. If it doesn’t, don’t accept the change just because the AI builder said it worked.

Step 7 — Write the user back, even if you didn’t fix it

The user who messaged you at 1:47am is not expecting you to be online. But if you are, a short reply matters more than a fix would:

“Thanks for letting me know — I’m looking at it right now. I’ll send you a note as soon as it’s working again.”

If they’re a paying user, that one message is the difference between them telling people you respond fast and telling people you ghosted them. The fix can wait until morning. The reply can’t.

The bigger lesson: build your app like it might break

If you found this stressful, the silver lining is that the experience will reshape how you build. After your first 2am incident, you’ll start doing things differently:

You’ll add a status check. A simple page that tells you whether the important parts of your app are working, so you don’t have to log in to find out.
You’ll keep a backup of the user data. Most AI builders will export your data on request. Doing this once a week takes 30 seconds and saves you in a worst case.
You’ll write down what your app depends on. A short list of every connected tool (payments, email, database, storage), so when something breaks at 2am, you have a checklist instead of guesses.
You’ll change one thing at a time. When you make 10 changes at once and the app breaks, you have no idea which change broke it. When you make one change at a time, you do.

You can build an app without coding. You can also keep one running without being a developer — but the skills involved are different from the building skills. You learn them mostly the hard way, usually at an inconvenient hour.

The good news: every time it happens, it gets less scary. By the third time, it’s annoying instead of frightening. By the tenth, it’s just Tuesday.