You shipped something with AI or a no-code tool, and now a worry has landed on your desk. A feature broke. A user asked whether you store their data "properly." A payment failed in a way you do not understand. Your instinct is to reach for an expert, because the problem feels bigger than you. But hiring a developer or a lawyer for the wrong worry wastes money, and skipping one for the right worry can cost you far more.
This guide is a triage tool. It takes the concrete worries that show up across ownership, security, payments, and policy work, and sorts each one into a bucket: handle it yourself, direct the AI to handle it, hire a developer, or hire a lawyer. For every bucket there is a signal that tells you when a worry has grown past your reach. You are not deciding whether you are "technical enough." You are deciding which worry belongs to which kind of help.
Before you triage anything, it helps to know how healthy your app already is. If you have not run the ownership audit yet, do that first. A worry looks very different when you already know your data is backed up and your logins work than when you have no idea what state your app is in.
The four buckets
Every worry a solo builder faces can start in one of four places. The goal is to name the smallest bucket that can honestly solve the problem, then escalate only when a clear signal tells you to.
Do it yourself. Config changes, content edits, turning features on and off, reading logs, checking backups, updating a policy page from a plain template. These need attention and care, not a specialist. Most day-2 maintenance lives here.
Direct the AI. Bugs and small features where you can describe what is wrong and what "fixed" looks like, and where a mistake will not touch money, logins, or personal data. You stay the decision-maker; the AI does the typing. This bucket is larger than most new builders think, and we cover how to work it in fix it yourself, direct the AI, or hire a developer.
Hire a developer. Problems where a wrong move has real consequences you cannot easily undo: anything touching authentication, payment processing, data you cannot afford to lose, or a bug you have tried to fix twice and made worse. Also anything you genuinely cannot describe well enough for the AI to act on safely.
Hire a lawyer. Questions about what you are legally required to do, what your liability is, what a contract or policy actually commits you to, or how a regulation applies to your specific situation and location. A lawyer answers "am I allowed to" and "what am I on the hook for." A developer answers "how do I make this work."
The line between the last two matters. A developer can implement a cookie banner; only a lawyer can tell you whether your particular banner meets your obligations where you operate. Everything about legal and compliance in this guide is educational, not legal advice. Confirm anything with real stakes with a qualified professional for your situation.
Common worries, sorted
Here is how the worries that come up most often map to a starting bucket. Treat the bucket as your first move, not a verdict. The next section covers the signals that push a worry up a tier.
| Worry | Starting bucket | Notes |
|---|---|---|
| A button or page stopped working | Direct the AI | Describe the broken behavior and the expected behavior. Escalate if it touches login or payment. |
| You want to change wording, colors, or layout | Do it yourself | Usually a content or config edit. |
| A form is not sending emails | Direct the AI, then developer | Fine to try directing the AI; escalate if the fix involves keys or a third-party account. |
| You are not sure your data is backed up | Do it yourself | Check first. If no backup exists, set one up before anything else. |
| A user says their login is broken | Hire a developer | Auth issues can hide security problems. Do not experiment on live logins. |
| Card payments are failing or double-charging | Hire a developer | Money-movement bugs are a hard escalation. See the signals below. |
| Someone asked how you handle their personal data | Hire a lawyer (with a developer to implement) | The "what must I do" part is legal; the "how do I do it" part is technical. |
| You need terms of service or a privacy policy | Do it yourself first, lawyer if stakes are real | Start from the minimum terms and policies; get review if you handle payments or sensitive data. |
| You think you were hacked or data leaked | Hire a professional now | Both a security professional and, likely, a lawyer. Stop and get help. |
| You want to add a whole new feature | Direct the AI or hire a developer | Depends on how well you can specify it and what it touches. |
| A vendor emailed about a "compliance requirement" | Hire a lawyer | Verify what actually applies to you before you act or pay. |
Two things this table deliberately does not do: it does not tell you to always hire, and it does not tell you to always self-serve. Plenty of worries are safely yours. The skill is knowing which.
The signals that escalate a worry
A worry moves up a tier when a specific signal appears. These are the triggers to watch for.
Signals to hire a developer
Move a worry from "direct the AI" to "hire a developer" when any of these are true:
- The problem touches authentication or user accounts. Login, password reset, sessions, and permissions decide who can see what. A subtle mistake here can expose one user's data to another.
- The problem touches payments or billing. Charges, refunds, subscriptions, and anything involving a payment provider's keys. Bugs here move real money and are hard to unwind.
- The problem could destroy or expose data you cannot recreate. Database changes, bulk edits, deletions.
- You have tried the same fix twice and the app is worse each time. Two failed attempts is your signal to stop, not to try a third.
- You cannot describe the problem clearly enough to hand off. If you cannot write the ticket, the AI cannot act on it safely either.
Hard triggers that always warrant a professional
Some worries do not start in a lower bucket at all. These are the ones where "try it yourself" is the wrong instinct from the first moment:
- Any sign of a breach or leak. Unexpected data exposure, accounts you did not create, data appearing where it should not. Get a security professional involved and read when to hire a security professional for what to ask for. Preserve evidence; do not start deleting things.
- Anything that stores or transmits payment card details yourself. The standard answer is to let a payment provider handle card data so you never touch it. If you find your app is storing card numbers, that is an immediate stop-and-get-help situation.
- Auth or access-control bugs where one user can reach another user's data. This is a security incident, not a normal bug.
- Collection of sensitive personal data (health, financial, government IDs, data about children) beyond a basic contact form. The obligations here are real and location-specific.
For these, the cost of getting expert help is small compared to the cost of guessing.
Signals to hire a lawyer
Move a worry to a lawyer when:
- The question is "am I required to" or "what am I liable for," not "how do I build it."
- A contract, terms document, or vendor agreement commits you to something and you are not sure what.
- A regulation, law, or "compliance requirement" is named and you do not know if it applies to you.
- You handle personal data across borders, take payments, or serve a regulated audience. What the law requires changes with your jurisdiction and your risk level, so a template alone will not tell you if you are covered.
Payments and legal questions are the two areas where this guide is a starting point only. Flag both for expert review before you rely on your own read.
How to hire well once you have decided
Deciding you need help is half the work. Hiring well is the other half, and it is where solo builders most often overpay or get burned.
Scope the work before you reach out. Write down what is broken or unclear, what you have already tried, and what "done" looks like. A tight description gets you a faster, cheaper, more accurate answer, whether from a developer or a lawyer.
Ask for a bounded first engagement. Instead of an open-ended relationship, ask for a specific deliverable: "diagnose why payments double-charge and tell me the fix and the risk," or "review my privacy policy against how I actually handle data and list the gaps." A small, defined piece of work lets you judge the person before you commit more.
For a developer, ask how they will avoid breaking things. Will they work on a copy, not your live app? Will they explain the change in plain language so you understand what you now own? Can they leave you notes so the next fix is easier? You are hiring someone to hand the app back to you in better shape, not to become permanently necessary.
For a lawyer, ask about your specific situation. Where you operate, who your users are, and what data you touch all change the answer. A lawyer who gives you a generic template without asking about your context is not doing the part you cannot do yourself.
Do not treat a marketplace rating as a decision. Ratings and rankings vary and are easy to game, so use them as one input, not the answer. This guide does not endorse any specific vendor or marketplace. Some tool links elsewhere on Kodbe may be affiliate links, disclosed on our disclosure page; the professionals you hire should be chosen on fit, not on any referral.
Keep owning it afterward. The goal of hiring is not to hand the app off forever. It is to get past a specific worry and come back understanding your app a little better than before. Ask the person to explain what they changed and why.
In Plain English
What this is: a triage table that takes a specific worry and points you at the smallest honest solution, from doing it yourself up to hiring a developer or a lawyer, plus the signal that tells you when to escalate.
Who it helps: a solo builder or citizen developer who shipped an app with AI or no-code tools and now faces a worry they cannot categorize, so every problem feels like it might need an expensive expert.
When to use it: the moment a worry appears and before you spend money on help. Find the worry in the table, note its starting bucket, then check whether any escalation signal applies.
What to do next: run the ownership audit so you know your app's baseline, then use this guide to place your current worry. If it lands in a professional bucket, use the "how to hire well" notes to scope the work before you reach out. For launch-time worries, walk through the ship-responsibly pre-launch checklist, and browse the Ship Responsibly hub or the fixes library for worked examples.
A few quick questions
Can I ever DIY a security worry? You can and should do the detection work yourself: check backups, read logs, note anything odd. But once you see a real sign of a breach, an auth flaw, or card data where it should not be, that is a hard trigger to bring in a security professional.
How do I tell a developer problem from a lawyer problem? Ask what the question really is. "How do I make this work" is a developer. "Am I allowed to do this, or what am I on the hook for" is a lawyer. Many privacy worries are both, in that order.
Is the legal guidance here enough to rely on? No. Everything about terms, privacy, and compliance in this guide is educational, not legal advice. It helps you decide whether to call a lawyer; it does not replace one for your specific situation and location.
What if I genuinely cannot afford to hire anyone? Then narrow the worry until it fits a bucket you can handle, and do not touch the hard-trigger areas (payments, auth, personal data, suspected breaches) on your own. For those, the right move is to pause that feature, not to guess.
Start by scoring your app with the ownership audit, then bring your current worry back to this table and decide who, if anyone, to call.
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.