Common AI Building Problems:10 Fixes That Unstick You
The 10 most common AI building problems, decoded: what you see, what is actually happening underneath, the exact fix — and the prompt that gets you unstuck.
When you get stuck building with AI, it is one of the common AI building problems — almost never a new one. The same ten scenarios account for nearly every "I have no idea what to do next" moment a non-technical founder hits — and every one of them has a known cause and a known fix. Getting unstuck is not heroics. It is pattern-matching.
This is the curated top ten from a list of twenty stuck scenarios I keep for students in the AI Product Builder course — the ones that come up over and over. Find your symptom in the table, understand what is actually happening, apply the fix. If you have not yet learned to read error messages in the browser console, do that first — it turns every scenario below from a mystery into a diagnosis.
Why you get stuck (and why it is never random)
Every stuck scenario has one of three roots. Either your environment drifted (the database is out of sync with the code, a setting is missing, a cache is stale), your code has a specific defect (a typo, a missing check, a wrong import), or your data is not what you think it is (filtered out, in the wrong account, marked inactive). AI-generated code adds a twist: the code often works — it is the assumptions around it that break.
That is why "try again" rarely works and why systematic beats frantic. Match the symptom, check the root, apply the fix.
The 10 most common AI building problems, decoded
| What you see | What is actually happening | The fix |
|---|---|---|
| 400 Bad Request, "column does not exist" | The code expects a database column that was never created — code and database are out of sync | Apply your pending database migrations, then check the table in your Supabase dashboard to confirm the column exists |
| Data exists but does not show up | The data is being filtered out: inactive flag, draft status, or it belongs to a different account | Check the row in your database dashboard — look at flags like is_active and the account it belongs to |
| 401 Unauthorized | Your session expired or you got logged out | Sign out, sign back in; if it persists, clear the site data in your browser and sign in fresh |
| 403 Forbidden or 406 Not Acceptable | You are logged in but the database security rules (RLS) block the operation | Check your user role and the security policies on that table in the Supabase dashboard |
| Duplicate key violation | You are creating something with a name or address that already exists — those must be unique | Use a different value, or update the existing record instead of creating a new one |
| Cannot read property of undefined | The code runs before the data arrives from the database | Ask AI to add a loading check before the data is used |
| Module not found | A typo in an import path, a file that does not exist, or a package that was never installed | Check the exact spelling and capitalisation of the path; run the install command; restart the dev server |
| Build failed on deploy | Type errors ignored locally, or settings (environment variables) missing on the hosting platform | Run the build on your machine first to see the real error; copy every environment variable to the hosting dashboard |
| Deployed, but the site shows the old version | Your browser or the CDN is serving a cached copy of the old site | Hard refresh (Cmd + Shift + R); test in a private window; redeploy with cache cleared |
| Changed code, nothing happens | The dev server is not running, the file was not saved, or you edited the wrong file | Check the terminal is running the server, save the file, hard refresh — then confirm you edited the file the error actually points to |
Three problems that are really one problem
Look at rows two, three, and four again. "Data not showing", "401", and "403" feel like three different disasters, but they are one family: identity and permissions. The database always asks the same three questions — who are you, what account do you belong to, and are you allowed to do this? When any answer is wrong, you get one of those three symptoms.
So debug them in that order. First: am I actually logged in? Second: is this data in my account, or did I create it under a different email? Third: does the security policy on this table allow my role to do this? Nine times out of ten, you never reach the third question.
Works on your machine, breaks in production
The most demoralising scenario deserves its own section: everything works locally, you deploy, and the live site is broken. Nothing "went wrong" — local and production are simply different environments. Different settings, different database, different build mode. The checklist:
- Environment variables first. Every setting your code reads must exist in the hosting platform's dashboard, not just on your machine. This is the cause more often than everything else combined.
- Check which database you are pointing at. Your live app must use your production database address, not a development one.
- Read the deployment logs. Your hosting platform records errors that never appear on your machine.
- Build locally like production. Run the production build command on your machine — if it fails there, you have found your bug without another deploy cycle.
The prompt that gets you unstuck
When the table does not settle it, hand the problem to AI properly. Vague pleas produce vague guesses — and a guessing AI can make things worse, as I showed in how AI sabotages your codebase. The unstuck prompt has four parts:
I am stuck on [what you were trying to do]. What I expected: [expected result]. What actually happens: [exact symptom]. Full error message: [paste it, with file and line]. What I already tried: [your list]. Diagnose the most likely cause before proposing a fix.
That last sentence matters. Forcing a diagnosis first stops AI from firing random fixes at your codebase — the debugging equivalent of a doctor prescribing before examining. And one habit prevents half of this article from ever happening to you: commit working code before every experiment, so "everything was working and now it is broken" always has a one-command exit.
The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →Frequently asked questions
What should I do first whenever I am stuck?
Open the browser console and read the actual error — here is how to read any error in 30 seconds. Then check the terminal where your dev server runs. Between those two places, the real cause is almost always written down for you; the skill is looking before guessing.
Everything was working yesterday and I changed nothing. What happened?
Something changed — you just did not notice it. The usual suspects: you pulled new code without updating dependencies or the database, a merge went wrong, or a file was accidentally reverted. Ask your version control what changed since the last working state, and restore from there. This is why committing working code often is the cheapest insurance in software.
When should I stop debugging and ask AI for help?
After one systematic pass: console read, symptom matched against the common scenarios, one fix attempted. If that does not resolve it, paste the full context — error, expectation, what you tried — using the unstuck prompt above. Twenty minutes of stubborn solo guessing is worth less than two minutes of well-prepared asking.
Are these problems a sign I should not be building without a developer?
No — every developer on earth hits these exact scenarios; they have just seen them enough times to recognise the patterns. That recognition is learnable in weeks, not years. The ten rows above are the majority of what "years of experience" means for day-to-day debugging.
How trapped are you, really?
Take the Corporate Suffocation Index, the free solopreneur readiness assessment.