Something in your app is broken, and you are stuck on a harder question than the bug itself: are you the right person to fix it? Sometimes the honest answer is yes, and you can handle it in ten minutes. Sometimes the answer is that you should hand it to the AI with a careful brief. And sometimes the answer is that you should stop touching it and get a professional involved before you make things worse.
This guide gives you a way to tell those three cases apart. Not a vague "it depends," but concrete thresholds you can apply to the specific problem in front of you right now. The goal is a safe choice, not a heroic one.
In Plain English: three lanes and how to pick one
There are three lanes for handling a problem, and they line up with how much damage a wrong move could do.
Fix it yourself is for routine, reversible, low-stakes changes. Copy tweaks, a broken link, a setting toggle, swapping an image. If you can undo it in seconds and nothing important depends on it, you are in this lane.
Direct the AI is for well-scoped changes you can back up and test before they go live. A specific function that formats a date wrong, a form field that should be required, a layout that breaks on mobile. You understand what should change, you can describe it clearly, and you have a safety net if the AI gets it wrong.
Hire a professional is for anything that crosses a red line: suspected data loss, payment handling, user authentication (logins and accounts), or personal data. These are not DIY territory and they are not "let the AI try" territory either. They are get-help territory.
The rest of this guide walks through each lane and gives you a self-check and a scoping script so you can pick with confidence. If you want the calm, step-by-step version of first response when something breaks, start with the calm first-response guide when your app breaks.
Fix it yourself: routine, reversible, low-stakes changes
The DIY lane is wider than most non-technical builders think, and that is good news. A lot of what breaks in an app is cosmetic or content-level, and you are perfectly capable of handling it.
You are in the fix-it-yourself lane when all of these are true:
- The change is routine: text, links, images, a visible setting, a toggle.
- The change is reversible: you can undo it immediately if it looks wrong.
- The stakes are low: if it stays broken for an hour, nobody loses money, data, or access.
- You understand what you are changing and why.
Concrete examples: fixing a typo on your pricing page, updating a phone number, replacing a hero image, correcting a link that points to the wrong page, changing a headline. None of these can lose customer data or lock anyone out. If you get it wrong, you change it back.
The one habit that keeps this lane safe: make one change at a time and look at the result before moving on. When you stack five edits and then check, you cannot tell which one caused the problem. One change, one check.
If a "routine" change starts sprawling (you meant to fix a link and now three pages look wrong), that is a signal you have left this lane. Stop and reassess rather than pushing through.
Direct the AI: well-scoped changes you can back up and test
The AI lane is for problems that are more than cosmetic but still bounded and low-risk. You know roughly what needs to happen, you just do not want to write the code yourself. The AI can help here, but only inside a safety net you set up first.
Before you direct the AI to change anything, run this quick self-check. If you cannot answer yes to all four, you are not ready for this lane yet.
| Question | Why it matters |
|---|---|
| Can you back it up? | You need a saved version to return to if the change goes wrong. |
| Can you revert? | Knowing how to undo the change is what makes trying it safe. |
| Can you test it? | You need a way to confirm the fix worked before real users hit it. |
| Do you understand the blast radius? | You should know what else this change could touch if it goes sideways. |
That last one, blast radius, is the one people skip. A change to how prices display is contained. A change to how orders are saved is not, because a mistake there can corrupt real records. Same amount of code, very different risk.
Good AI-lane problems: a date showing in the wrong format, a validation rule that lets blank submissions through, a button that does nothing on tap, a section that overflows on small screens. Each is specific, testable, and does not touch money, logins, or personal data.
When you do hand a problem to the AI, be precise about what should change and what must not. And keep your expectations grounded: the AI is not guaranteed to get it right, and it may not even understand the code it wrote weeks ago. It is worth knowing why the AI cannot always fix what it built, because that is exactly the situation where people burn hours in a loop instead of stepping up to hire.
If two or three careful AI attempts do not fix it, treat that as a message. The problem is likely deeper than the lane you picked, and the next move is a person, not a fourth prompt.
Hire a professional: the red lines that mean stop
Some problems are not a matter of skill or patience. They are a matter of risk. On these, the right move is to stop and bring in a qualified person, and doing so early is the competent choice, not a defeat.
Here are the hard red lines. If your problem touches any of them, this is a hire situation, not a DIY or AI-lane situation:
- Suspected data loss. Records are missing, disappearing, or getting overwritten. Every additional change you make risks destroying whatever could still be recovered. Stop and get help.
- Payment handling. Anything involving charging cards, storing payment details, refunds, or checkout logic. Mistakes here cost real money and can carry legal and PCI obligations.
- Authentication. Logins, passwords, sessions, accounts, "who is allowed to see what." A bug here can expose one user's data to another. This is not a place to experiment.
- Personal data. Names, emails, addresses, health or financial details, anything about identifiable people. Exposure here is both a trust problem and, often, a legal one.
The reason these are absolute is the failure mode. A cosmetic bug that goes wrong is embarrassing. A data-loss, payment, auth, or personal-data bug that goes wrong is expensive, and sometimes it cannot be undone. That asymmetry is the whole reason for the red lines: the downside is too large to gamble on a DIY or AI attempt to save a bit of money or time.
Hiring is not always a single kind of help, either. Some problems justify both a developer and, for legal or PCI questions, a separate professional such as a lawyer or a compliance specialist. A developer can fix how logins work; only a qualified professional can tell you what a specific regulation requires of your business. This is educational guidance, not legal advice, and you should verify your own situation with a qualified professional.
Two guides can help you draw these lines for your own app: when to hire a security professional and what to ask for for security-specific decisions, and do you need a developer, a lawyer, or neither when you are unsure which kind of expert the problem actually calls for.
How to scope the work before you hand it to anyone
Whether you are directing the AI or hiring a person, the quality of the outcome depends on the quality of your brief. A clear scope saves you money with a developer and saves you frustration with the AI. Vague requests produce vague, risky work.
Use this short scoping script. Write down each part before you hand anything off.
- What broke. Describe the symptom in plain terms, and when it started. "Since Tuesday, the checkout button shows a spinner forever and never completes." Specific beats dramatic.
- What you tried. List what you already attempted and what happened. This stops a developer from repeating your dead ends and helps the AI avoid the same wrong turn.
- What must not change. Name the parts that are working and must stay working. "Do not touch how existing orders are stored." This is your single most important line, because it defines the blast radius for whoever picks up the work.
- Access boundaries. Decide, in advance, exactly what access you will grant and for how long. Give the minimum needed for the specific task, and plan to change any shared credentials afterward. You are handing someone the keys to your app; hand over the smallest set that gets the job done.
For a person, this script becomes the message you send when you reach out, and it signals that you will be an organized client. For the AI, it becomes the constraints you put at the top of your prompt so it does not "helpfully" rewrite something that was fine.
A quick note on access and security: if the problem is anywhere near logins, personal data, or payments, run the security self-audit before you grant anyone access, so you know what is sensitive and what to protect while the work happens.
In Plain English
What this means: every broken thing falls into one of three lanes. Routine and reversible means fix it yourself. Well-scoped, backed up, and testable means you can direct the AI. Data loss, payments, authentication, or personal data means stop and hire a professional. The lane is set by how much damage a wrong move could do, not by how hard the fix looks.
Who this helps: solo founders, indie hackers, and citizen developers who shipped something with AI or no-code tools and cannot tell whether a given problem is within reach or over their head.
When to use it: the moment something breaks and before you start clicking around. Run the self-check first, then act.
What to do next: identify which red line, if any, your problem touches. If it touches one, skip straight to scoping the hire. If it does not, run the four-question self-check to choose between fixing it yourself and directing the AI, then make one change at a time with a way to revert.
This is guidance to help you choose safely, not a guarantee about any outcome, cost, or result. Your specific situation may differ, and when it involves legal or PCI matters, confirm with a qualified professional.
A few common questions
Is directing the AI always cheaper than hiring? No. The AI lane is cheaper only when the problem is genuinely low-risk and well-scoped. On a red-line problem, "saving money" with the AI can cost far more if it corrupts data or exposes accounts. Cost is not the deciding factor; risk is.
What if I am not sure which lane a problem is in? Default to the more cautious lane. When you cannot tell whether something touches personal data or authentication, treat it as if it does until you have confirmed otherwise.
Does hiring mean I failed at building my own app? No. Choosing the right help for a high-stakes problem is what a competent owner does. Owning what you built includes knowing where your own line is.
How many AI attempts before I hire? As a rule of thumb, if two or three careful, well-scoped attempts do not fix it, the problem is deeper than the lane you chose. Stop looping and move to a person.
Not sure which lane you are in? Start at the Debug hub to work through the problem step by step, and if it is a security question, run the security self-audit before you decide anything. When the fix is done, the Secure hub can help you close the gaps that let it break in the first place.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.