This isn't the same as hiring for a normal bug fix
If you hired someone to fix a typo on a hand-built website, "just fix it" would be a fine job post — the scope is obvious, the risk is low. AI-built apps don't work that way, and treating them like a normal freelance brief is where most of these jobs go wrong.
When you build something with Bolt, Loveable, Replit, or similar tools, you get code that looks finished and runs — but the tool optimized for "this works in the demo," not "this is structured the way an experienced engineer would structure it." The visible bug you're posting about is often a symptom, not the actual problem. And because the underlying code wasn't written with intent, nobody — including you — knows how deep the real issue goes until someone looks.
What "just fix it" actually risks
Post "my login is broken, please fix" and here's what can happen: a Smith takes the job at a fixed low price assuming it's a quick config fix. They open the code and discover the auth logic is scattered across six components with no consistent session handling, the database has no row-level security at all, and the "broken login" is actually one symptom of a structural problem that touches half the app. Now you're both stuck — the Smith either eats the cost of a job that's 5x bigger than quoted, or comes back asking for more money for work you thought was already scoped. Either way, the job that should have taken an afternoon becomes a dispute.
This isn't a hypothetical edge case. It's the single most common failure pattern in AI-app rescue work, and it's almost entirely avoidable with a better job post.
What actually reduces the risk
Name the platform
"Built on Bolt.new with Supabase" tells a Smith what patterns to expect and what common failure modes to check first. Different AI builders have different characteristic weak points — a Smith who knows the platform can estimate risk before they even open the code.
Describe the symptom precisely, not your diagnosis
You don't need to know why it's broken — that's the Smith's job. But describe exactly what you observe: the error message, when it happens, what you expected instead. "Login is broken" could mean five different things. "Clicking 'Sign in with Google' redirects to a blank white page instead of the dashboard" is one specific, checkable thing.
Say what you've already tried
Even "I tried refreshing and it still happens" or "this started after I changed X" is useful — it rules things out and shows the Smith you've engaged with the problem, not just noticed it exists.
Ask for a scoping pass before a fixed quote on anything unfamiliar
If you don't know how deep the problem goes, don't ask for a fixed-price quote on "fix it all" — ask for a paid, bounded diagnostic first (an hour or two, capped cost) where the Smith investigates and comes back with an actual scope and quote. This costs a small amount upfront and saves you from the exact scenario above: a fixed quote that turns out to be wildly wrong once someone actually looks under the hood.
Set a boundary on what's explicitly out of scope
"I don't need this rebuilt, I need this specific flow working" is one sentence that prevents a huge amount of scope drift in both directions — it stops a Smith from scoping too broadly (padding the price defensively) and stops the job from quietly growing once work starts.
A before/after
Before:
My app doesn't work right. Please fix all the bugs.
After:
Built on Loveable with Supabase backend. Specific issue: after a user signs up, they land on a blank dashboard — browser console shows a 403 error on the /api/user endpoint. I haven't touched the code, this started happening after a Loveable auto-update. I don't need anything else changed — just need this flow working. If it turns out to be a bigger structural issue, let me know before doing more than a couple hours of work and I'll approve a new scope.
The second version gives a Smith enough to estimate honestly, and gives you a way to catch scope growth before it becomes a dispute instead of after.
The one-line version
AI-generated code doesn't have predictable scope the way hand-written code does — name the platform, describe the symptom precisely, and build in a checkpoint before committing to a fixed price on anything you haven't had looked at yet.