Your AI-built app breaks every time you change it: what to hand the fixer

The short answer

When every change to an AI-built app breaks something else, you do not have a lot of bugs. You have one structural problem that keeps producing them. Usually it is one of two things: the same decision lives in more than one place, so the tool updates one copy and leaves the other behind, or nothing checks the old behaviour after a change, so you only find out when a user does.

A freelancer can fix both, but only if you hand over more than “it keeps breaking”. Give them the code on your account, the last few changes before each break, three reproducible problems and a list of what must keep working. Ask for fixes plus automatic checks for that list. The brief on the AI-built app job page has the fields; this guide explains what to put in them when the problem is breakage after changes.

Why a change in one place breaks another

AI coding tools are good at the change you ask for. They are less reliable at noticing what else depended on the old behaviour, especially when the project has grown by many small requests.

I build and run my own unattended automations with an AI coding tool, and the breaks that cost me most were never in the part I had just changed. Three from my own records:

The same rule in two files. My publishing pipeline makes a slideshow post and a short video from the same material. I added several new layouts and extended the video renderer to handle all of them. But a second file, the one that decides whether a video gets made at all, still recognised only the original layout. All seven posts made in the new layouts over the next two days went into the queue without their video. The log said the video was “skipped”, which reads like a decision, not a failure. The lesson I wrote into the project notes: when two files make the same decision, changing one quietly makes the other out of date. Adding a new layout now means editing three named places, and the list is written down.

A new style that leaked. I added small diagrams to pages on a site of mine. Their styles were global, and one class name matched an existing one. The numbered steps on a different page, one I had not touched, started overlapping. The change was right; its scope was wrong.

A format switch that exposed an old assumption. When I switched a publishing job to video-only, one type of item could not be turned into a video. The preparation step skipped it but still counted it as prepared, decided the day’s quota was filled and stopped. Nothing was published from that evening until the next morning, with 13 items waiting, and the log looked like a quiet night (the full incident).

None of these were exotic. Each came from a reasonable change and an assumption stored somewhere else. That is the pattern a good fixer looks for.

What to hand the freelancer

“It’s buggy” gets you a vague quote and a patch. These six get you a diagnosis.

Items 2 and 4 are the ones buyers skip, and they are the ones that turn a repeat problem into a one-time fix. The job page’s brief has fields for the rest.

What to ask for back

A fix that stops today’s bug is half the job. Ask for three things that stop the next one:

Ask for	Why it matters
A short note per fix: what broke, where, and why	Tells you whether it was a one-off or a duplicated decision
Automatic checks for your “must keep working” list	The next change that breaks one of them fails the check, not your user
A list of places where one change needs another	Like my “three places” note: written down, in the repository

If you work with an AI coding tool yourself, also ask for its instructions file to be updated with those rules. Most tools read a project file of standing instructions before every change. A line like “a new layout must be added in these three files” is exactly the kind of thing that file is for. What a Claude Code expert actually does covers that file and the other deliverables in more detail.

A brief you can copy

The problem: Every time I change something, something else breaks. Recent example: [change] → [what broke]. Code: [repository or export link], on my account. Live version: [branch]. Three problems to reproduce: 1. [steps / expected / actual] 2. […] 3. […] Must keep working: [5–10 plain sentences] Money and personal data: [logins, payments, uploads, what users must not see of each other] Scope: Fix the three problems, find where decisions are duplicated, add automatic checks for the must-keep-working list. No redesign. Hand-back: All changes in my repository, a note per fix, a list of places that must change together, and a README on how to run the checks. Acceptance: Final payment when the three problems no longer reproduce on the live app and every check runs and passes. I will keep editing with: [tool, or “a developer”].

For how to accept the work, use the acceptance list on the job page. Add one test of your own: make one small, harmless change yourself after delivery and run the checks. If they catch nothing when nothing broke, and you can read what they checked, you have what you paid for.

Choosing the size of the first order

If you are not sure whether the app is worth fixing, order a paid review first and decide after. The reviews I counted for developers who fix AI-built apps show both small orders and large ones, and most came from buyers who ordered again. That fits a pattern of starting small: a review or a scoped fix, then a larger job with the same person if the first one went well.

What moves the price here is mostly how many places the same decision is duplicated and how much of the app touches money or personal data, not the number of screens.

Where it goes wrong anyway

• You ask for a redesign in the same order. Mixing new features with the stabilising work hides which change broke what. Fix first, then change.
• The checks cover screens, not outcomes. “The page loads” is not a check. “An order is charged once” is.
• Nobody runs the checks after delivery. Ask the fixer to show you how, and run them yourself before and after your next change. Agreeing who fixes later breaks belongs in the contract too: see putting maintenance in the contract.
• The AI tool keeps rewriting the fixed parts. This is what the instructions file and the “change together” list prevent. If your tool ignores them, tell the fixer; it may be a sign to move that part out of the tool.

Wrap-up

Repeated breakage is a structure problem wearing the costume of many small bugs. Hand over the changes that caused the breaks and the list of what must keep working, not just a list of symptoms. Ask for fixes, checks and a written map of what must change together. Then the next change you make is a small risk you can test, not a gamble you find out about from a user.