I built a product with AI—how to make improvements without breaking what works

Learn more about working with models in the Ailoot documentation.

Why can maintaining an AI-built product cost more than launching it?#

You built an app in an evening, published a link, and sent it to your friends. It works. Then a week later, the first real person shows up, clicks something the wrong way, and half the features stop working. You ask Claude to fix it—it fixes one thing and breaks another. Sound familiar?

And this is where the main question comes up: what do you do after launching a product, once the euphoria of the first working prototype has passed and you still have to maintain it somehow? You could call this vibe coding for grown-ups. Building is excitement and speed. Maintenance calls for a cool head: you understand what you’re changing and keep it under control. Most people fail at this second part because nobody prepares for it.

An industry analysis of more than a million code changes from 2,444 teams calculated where the money spent on AI development actually goes. Here’s the picture:

The “Hidden cost of vibe coding” guide explains these figures in more detail. There, the question was what you’re paying for. Here, the question is different: 44 cents of every dollar go toward fixing bugs—and this whole article is about keeping that share from growing. The work of keeping it in check is called maintenance.

The difference between someone who vibe-codes for grown-ups and someone who just babysits a neural net shows up after launch. The first person’s codebase grows, they make improvements, and nothing breaks. A month later, the second person’s product has turned into a leaky contraption they’re afraid to touch. Next, I’ll explain how to end up in the first group.

What actually breaks: 5 post-launch disasters#

These are public postmortems of real products built with AI, with numbers and dates. Think of them as a minefield map—each mine has already gone off for someone, and the way around it is known.

All five have the same root cause. By default, AI makes things work right now, not safely a month from now under load. You can’t see the difference while developing on your computer. It becomes apparent when the first stranger with bad intentions shows up.

Writing code by hand isn’t the problem—many people work this way. The problem is not asking, “Is the database secured?” Next, I’ll show you a prompt that asks this question for you.

The first safety net is git and rolling back to “how it was yesterday”#

When Claude breaks something, you need a “put it back the way it was yesterday” button. Technically, that button is called git, and it’s simpler than it sounds.

Three terms a non-programmer needs to understand:

1. Repository — your project folder saved in the cloud (usually on GitHub). A copy of all your code that doesn’t live only on your computer.
2. Commit — a return point. You’re effectively telling the code, “save in this state.” Each commit is a marker you can return to.
3. Deploy — a move. The code was local, on your computer, and only worked for you. Deploy sends it to an external server so it works for everyone.

As long as you have recent commit points, you can roll back any breakage with one sentence. Literally.

I broke something—everything worked yesterday, but today it doesn’t. Find the latest commit where everything was fine, show me what has changed since then, and roll the project back to that state.

Two rules to put in place right away, before other people see the product:

• The repository must be private. Not public. Otherwise, anyone can read your code and everything in it.
• Put the secrets file on the ignore list. Keys, passwords, and database access credentials live in a separate file (usually .env), and that file never goes into the repository. Add a line for .env in .gitignore, and the secrets stay with you.

There’s a separate guide to safely rolling back changes in Claude Code: How to roll back changes in Claude Code. Without return points, you’re walking a tightrope without a safety net, and sooner or later you’ll fall.

What does /rewind roll back, and what doesn’t it?#

Claude Code takes a snapshot of the state before each change it makes. The /rewind command (or pressing Esc twice) rolls back both files and conversation to a selected point. It’s handy: if you broke a feature five minutes ago, you can go back five minutes.

But there’s a trap that causes beginners to lose data. /rewind doesn’t roll back everything:

Anthropic itself puts it plainly: snapshots are a local “undo” button, while git is permanent history. Snapshots complement version control, but don’t replace it.

The practical takeaway for a non-programmer: /rewind will save you from “Claude just broke a feature.” But if it managed to delete a database row or upload code to the cloud, only git and a database backup can bring it back. So keep both layers: snapshots for quick rollbacks, commits for the project’s permanent history.

How do you make improvements without breaking what already works?#

Every second person gets caught in this loop. You ask AI to fix a small bug. It suggests a reasonable change. That change breaks something else. You ask it to fix the new issue, and two more problems appear. And so on.

The loop happens because vibe coding is nondeterministic. The same prompt gives you different code twice. So each edit can quietly shift the surrounding logic: the discount threshold moves from 10 to 12 percent, or a validation rule changes its behavior—with no checks on your part and not a single warning. This is called logical drift, and it quietly damages exactly the things that bring in money: prices, access, and payments.

There’s one rule to guard against drift, and it’s simple enough to put up on a wall: don’t commit code you couldn’t explain to another person word for word.

In practice, this becomes a ready-made wrapper to use before any change to working code. It makes AI take small steps and show you exactly what changed.

Before changing the code, do this:

Save the current working state as a separate return point (commit).

Describe in words exactly what you plan to change and in which files.

Make the smallest possible change—only what solves my task, nothing extra.

Show me what changed and explain each change so I could explain it to another person.
Don’t touch pricing, access, or payment logic unless I asked you to.

Another principle that saves weeks is discipline around task boundaries. One pain point, one change, quick implementation. Don’t ask AI to rewrite half the project in one prompt. Professional developers sometimes start building an entire Uber when all they needed was one button—and stretch it out for months. You don’t need that.

Everything I describe rests on one thing: managing context. To keep AI from breaking neighboring logic, it needs to remember your project’s rules.

How do you check a change before publishing it?#

Between “it works on my computer” and “it works for everyone” there’s an intermediate step beginners skip: a test copy. It’s a separate snapshot of your production environment where you check a change before real people see it. The working cycle looks like this:

1. Build and check the change yourself (development).
2. Deploy it to staging—a copy of production, but without real users.
3. Run the key scenarios and make sure nothing has shifted.
4. Only now deploy it to production.

Why this matters after launch: every release carries risk. A small code change can break account sign-in. One missing setting can bring down the entire product. Staging catches these issues without consequences; in production, you lose customers.

To avoid checking everything manually every time, give AI a prompt to compare the new version’s behavior with the old one in the critical areas.

I’m about to deploy a change. Run through the product’s key scenarios in order and check that each one still works as before:

New user registration and sign-in.

Payment and access granted after payment.

Access rights—a regular user can’t see someone else’s data or the admin area.

Key business logic figures (prices, discounts, limits) haven’t changed.
If anything behaves differently from the previous version, stop and show me exactly what changed.

Where are your secrets? A beginner’s biggest hole#

I’ll explain the biggest landmine in detail because it takes out more products than any other. When AI writes code, the easiest thing is to put a key where it will work right away—directly in the code for the page that opens in the browser. You won’t notice the difference during development. But anyone can read anything that reaches the browser by opening the developer tools.

The founder who had customers charged $87,500 later said that a single prompt could have prevented it. The charges were eventually reversed, but nonrefundable fees and the lost peace of mind remained. Here’s that prompt.

Check the entire project and make sure no secret key ends up in the browser:

Find all keys for the database, payment system, and external services.

Make sure each one is stored only on the server, in environment variables, and not in page code.

Check the project history—did any key accidentally get into it earlier?
Show me a list of every place where you found secrets and what needs to be done about each one.

The next landmine nearby is checking access rights only on the browser side. If your product decides whether to “show the admin area” in page code, anyone can bypass that decision. Access rights must always be checked on the server. The database must return data only to those entitled to it—that’s what row-level security (RLS) is for, and it needs to be enabled on every table.

Before selling access or letting other people in, run a general security audit of the product.

Go through the project like an attacker and find security holes:

Are any secret keys stored in code that goes to the browser or in the project history?

Is row-level security (RLS) enabled on every database table, and are access rights checked on the server rather than only in the browser?

Is there an automatic database backup configured, and have I ever checked that I can restore from it?

Is the production database isolated from the environment where the AI agent runs?
For each item, tell me whether everything is fine or exactly what needs to be fixed.

There’s a separate, full guide to vibe-code security: How to secure a vibe-coded app. The rule is simple: treat anything AI did by default as unsecured until you’ve checked otherwise.

Where to host your product: the hosting ladder#

You don’t need to rent your own server and configure it manually right away—that’s a complicated task at the beginning and will eat up your time. There’s a ladder you can climb as the product grows:

1. Free hosting (for example, Vercel)—for yourself, tests, and small projects. It works if the platform is available to your audience and you don’t store people’s personal data.
2. A platform with one-command deployment (Railway)—when you have a backend and a database. You deploy with one command and don’t need to configure a server. The barrier to entry is minimal.
3. Your own dedicated server—when the load is high and you need full control. Move to this later, when you’ve hit the platform’s limit.

For a non-programmer who has just launched, the easiest option is a platform with one-command deployment, without manual server configuration. Move to your own server later. If you want to follow this path with a concrete example, see the guide to deploying a vibe-coded project to your own server with Coolify.

When should you separate the app, database, and backups?#

Three things shouldn’t be kept in one basket: the app, the database, and backups. While there are few users, everything lives together, and that’s fine. But there’s a clear signal for when it’s time to separate them.

• Put the app and database on different machines. The signal: at peak load, CPU and memory stay above 70–80 percent, requests slow down, and the app and database fight for the same resources. After separating them, you can strengthen the database without touching the app, and vice versa.
• Follow the 3-2-1 backup rule. Three copies of the data, on two different types of media, with one off-site. This protects against hardware failure and ransomware. The key is that backups must be automatic.

Backup frequency depends on how costly it is to lose data from several hours. For an online subscription service where losing an hour of payment records is unacceptable, the backup interval must be shorter than an hour, or you need verified transaction logs and point-in-time recovery (PITR). Choose the interval from the maximum tolerable data loss, and separately test the time needed to restore service. Once a day is enough for a blog. The logic is simple: decide how much data you can afford to lose and configure backups accordingly.

Help me decide whether it’s time for my product to move to more serious infrastructure. Check and ask me about each point:

How loaded are the CPU and memory at peak—is usage staying above 70–80 percent or not?

Are the database and app on the same machine or on different ones?

Is there an automatic database backup configured, and have I tested restoring from it?

Is there a separate copy of the environment (staging) for checking before deployment?
Based on the results, give me a clear recommendation: what to leave as is, what to split off first, and why.

There’s a separate question: managed database or your own. For a small team, managed is almost always better: your own is cheaper in hardware, but it eats up hours in maintenance. If you’re on your own and your product isn’t infrastructure, those hours cost more than the difference in server price.

How do you put maintenance on autopilot?#

Manual maintenance is exhausting. You can take it off your hands in two ways: monitoring and a patrol agent.

Monitoring uses two different tools for two different jobs:

1. “Is the site up?”—an uptime monitor (for example, UptimeRobot). It pings the product every few minutes and sends an alert if it goes down. There’s a free plan.
2. “What exactly broke?”—an error tracker (for example, Sentry). It collects errors inside the app and shows where and why something failed.

The first catches the fact that the product went down. The second shows which feature failed and why. Together, they address the question, “Will I find out about a failure before a customer writes to support?”

The second level of autopilot is a patrol agent. Imagine a real estate agency: at seven in the morning, an AI agent reads website inquiries, sees that the booking form is broken, finds the cause in the code, and brings you a ready fix with an explanation. You review it and say “yes”—it deploys. The order matters: first resolve the user’s problem (grant access, apologize), then investigate the cause and the money.

One more rule about AI’s access to the production database: give it a read-only user, and hide personal data behind an intermediary layer so the agent sees “name” instead of a person’s real name. Then, even if it makes a mistake, it physically won’t be able to delete or corrupt production data. The incident in the table above, where an agent wiped the production database, is exactly about the lack of this restriction. The guide What to do if AI deleted your database explains what to do if disaster has already struck.

When is it time to shut down a product?#

The most underestimated part of maintenance is knowing when to stop maintaining. Everyone who builds a lot has a graveyard of projects: built one, tinkered with it, then abandoned it. That’s normal, and it isn’t failure. Failure is dragging along for months something nobody uses, out of regret for the time spent.

Thresholds you can use to make the decision:

1. Two weeks—enough to see whether an idea works. If the first real users return, keep going. Silence is an answer.
2. Three months—the hard limit. If it hasn’t taken off in three months, shut it down. With the speed of vibe coding, spending six months testing one idea is too long.

Closing a project is psychologically hard, so treat it as a decision, not a feeling. Letting go of a project you’ve invested in is like firing an employee who can’t do the job: unpleasant, but keeping them costs more than letting them go.

Maintenance is work done to keep a product alive and useful to people. Everything else—git, backups, monitoring—is just a tool to help you get to the point where the product starts working for you every day.

Building a product with AI in an evening is half the job. Keeping it alive and secure as it grows—that’s what vibe coding for grown-ups means.

For your next step—Ailoot.