You built an app with AI. Here's how to keep it running.

Building the app was the fun part. You described what you wanted, the AI tool built it, you tweaked it, and after a few rounds it actually worked. Maybe it took a weekend. Maybe less.

Now it’s been three months. The app is live, people use it, and you’ve started to notice things. The database connection drops sometimes. The free tier sent you an email about “resource limits.” A user reported that something broke but you can’t figure out what changed. You haven’t touched the code in weeks, and you’re vaguely worried that it’s going to stop working and you won’t know why.

This is the part nobody talks about. Building an app is a project. Keeping it running is a job.

Why AI-built apps need more attention, not less

Here’s a thing that feels counterintuitive: an app built with AI code often needs more operational care than one built by hand. Not because the code is bad, but because:

• You didn’t write it, so you don’t know how it works internally. When something breaks, you can’t trace the logic in your head. You have to read code you’ve never seen before, written by a model that doesn’t explain its choices.
• AI tools generate dependencies generously. They pull in packages without thinking about whether you need them. Each package is a thing that can have security vulnerabilities, break in future updates, or conflict with other packages.
• There’s no institutional knowledge. A developer who builds an app by hand knows which parts are fragile. You’re starting from zero on an app that’s already in production.

None of this means AI-built apps are worse. They’re often perfectly fine code. But they need the same ongoing care as any production app, and the builder usually isn’t equipped to provide it, because building and operating are different skills.

What “keeping it running” actually involves

Let’s break this down into plain language. There are about six things that need to happen on an ongoing basis for any live app. None of them are exciting.

Backups

Your database needs to be copied regularly, and those copies need to be stored somewhere separate from the server. If the server dies, your backups shouldn’t die with it.

How often: daily at minimum. Weekly is gambling.

The catch: a backup is only useful if you’ve tested restoring from it. An untested backup is like a smoke detector with no batteries. It’s there, it looks reassuring, and it won’t help you.

Updates

The code your AI tool generated depends on other people’s code (packages, libraries, frameworks). Those other people find and fix security holes regularly. If you don’t update, your app slowly accumulates vulnerabilities.

How often: check monthly, apply security updates immediately.

The catch: an update can break your app. You need to test after updating. This is where a staging environment helps, a copy of your app where you can try changes before they go live. Most hobby projects don’t have one, which means every update is a gamble.

Monitoring

Something needs to check that your app is actually reachable, ideally every few minutes. When it goes down, you need to know before your users do.

How often: continuous, automated.

The catch: knowing it’s down is only useful if you can fix it. At 3am on a Wednesday, are you going to wake up and debug a server? Probably not. And that’s okay for a hobby project, but it’s worth being honest about.

Security patches

The operating system your app runs on needs patches, just like your phone needs updates. Unpatched servers are the most common way small apps get compromised.

How often: monthly at minimum, critical patches immediately.

The catch: you need SSH access to the server and enough command-line knowledge to run the update safely. For most non-technical builders, this is the task that feels most foreign.

Log review

When something goes wrong, logs are how you figure out what happened. “The app crashed” tells you nothing. “The database connection timed out at 14:32 because the connection pool was exhausted” tells you exactly what to fix.

How often: when something breaks, at minimum. Ideally, a weekly glance.

The catch: AI-generated code often has minimal logging. The logs might say almost nothing useful. Adding better logging means editing code you didn’t write, which brings us back to the first problem.

Certificate renewal

Your app’s HTTPS certificate (the thing that makes the padlock appear in the browser) expires every 90 days. If it expires, browsers will show a scary warning page and your users will think your site got hacked.

How often: every 90 days, but it should be automated.

The catch: if you set it up with a tool like Caddy, it’s genuinely automatic. If you set it up manually, it’s a ticking time bomb you’ll forget about.

The real cost of doing this yourself

Add it up. You’re looking at 2 to 4 hours a month of ongoing maintenance, assuming nothing goes wrong. When something does go wrong, and eventually it will, add another 3 to 10 hours of debugging time, mostly spent reading code you didn’t write, googling error messages, and trying fixes that might make it worse.

For a hobby project, this is a fine tradeoff if you enjoy learning ops. Some people do. It’s genuinely interesting work, and you’ll learn skills that transfer to bigger projects.

But if you’re the kind of person who built an app with AI specifically because you didn’t want to learn programming, doing your own ops is going in the wrong direction. You automated the building. Now automate the keeping-it-alive part too.

The three tiers of “someone else handles it”

Depending on where your project is, you need a different level of help:

Your project is small and personal (€9/mo Hobby). A few dozen users, no payments. You need the app to stay awake, update safely when you push, and live at a real web address. That’s Hobby. Your data stays where it already is, usually Supabase, and support is by email.

Your project has real users who depend on it (€19/mo Launch). Strangers use it and would notice if it broke. Same setup as Hobby, plus a human who answers within 4 business hours when something goes wrong.

Your project holds data you can’t lose (€59/mo Growth). Bookings, orders, anything people paid for. We run a Postgres database for you, back it up automatically and test the restores. Past that, Business (€249/mo) adds 24/7 cover and an uptime guarantee, but if you’re reading this article, you’re probably not there yet.

A task you can do right now

Open whatever AI tool you used to build your app. Look for an “Export” or “Connect to GitHub” button. Click it. Get your code into a GitHub repository you own.

This is the single most important step for any AI-built app. As long as your code only exists inside the builder’s platform, you’re completely dependent on that platform. If they change their pricing, shut down your project’s tier, or have an outage, you have nothing.

With your code on GitHub, you can move it anywhere. To Stackbastion, to another host, to your own server. It’s your code. Make sure you actually have it.

After that, request a free audit. We’ll tell you what’s solid, what’s risky, and what it would take to get your project running on its own infrastructure. No charge, no commitment, and we write the report in plain language.