booting
imelabs
← the notebook
post · jun 2026

vibe-coded and stuck

non-technical founders who half-built an app in lovable, bolt or cursor and then hit a wall. why the last 20% stalls them, what actually breaks, and the honest way out.


you described an app to lovable, bolt or cursor, and in an afternoon you had something that looked like a real product. then you went to add the part that makes it a business, accounts, payments, real data, actually going live, and it stopped working, and the ai stopped being able to fix it. you are not a beginner staring at a blank screen. you are someone holding 80% of an app with no way to finish it.

that is a specific, common situation. it even has a name now: "vibe coding", coined by andrej karpathy in february 2025. his founding description already flagged the wall, that when the ai cannot fix a bug you end up asking it for random changes until the problem goes away, and the code grows past your understanding. that point, where asking for random changes stops working, is the one this is written for.

why you get stuck: the real reason

the first 80% and the last 20% are different kinds of work. ai builders are genuinely good at the part that vibes: the interface, the happy path, the demo that wins a room. they fall down on the part that does not vibe, because there is no vibe to follow. authentication done properly. payments that handle a declined card instead of failing silently. a data model that survives real use. security. deployment. performance under load. that last slice is most of the actual engineering, and it is invisible until it breaks, at which point it tends to break all at once.

it is not a feeling, the code is measurably worse

this is not snobbery, and i can show it. a december 2025 analysis of hundreds of github changes found that ai-co-authored code carried roughly 1.7 times more major issues than human-written code, with security vulnerabilities almost three times as common and misconfigurations up by about three quarters. separate longitudinal work found code duplication roughly quadrupling and churn nearly doubling as ai tooling spread. one widely shared incident had a coding agent delete a production database despite being told to change nothing. the wall is real, and it is structural, not a skill issue on your part.

the trap is that it looks finished

the cruel part is the appearance of done. a demo that runs on your screen feels like a product, so you, and your investors, believe you are 90% there when by effort you are closer to half. and the half that remains is the hard, unglamorous, everything-that-can-go-wrong-in-production half. that gap is exactly where this cohort lives: real momentum, sometimes real money already taken, and a thing that cannot safely go live.

what actually breaks

the failure modes cluster in the same handful of shapes. usually some of: api keys sitting in the browser for anyone to read, a database deployed with its security rules switched off, no real authentication behind the login screen, payments that work once and fail quietly the second time, no error handling anywhere, and the whole thing on a free tier that pauses the moment real traffic arrives. each of these is a live liability, not a line on a to-do list.

what i do for this buyer

the easy move here is to bin your work and bill you for a ground-up build. i do not lead with that. depending on what you have actually got:

  • finish it. take the 80% and engineer the last 20%: auth, payments, security, a data model that holds, deployed properly and handed over fully owned.
  • harden and ship it. if the foundation is sound, i make it safe and put it live.
  • tell you the truth about it. if the foundation is not sound, i will say so, and say plainly what it costs to fix versus rebuild. and sometimes the honest answer is that what you have built is genuinely fine for what you need, and you do not need me yet. you will get that answer too.

the deeper issue is ownership

underneath all of this is the same problem that runs through everything i build: a vibe-coded app you cannot finish is a thing you do not really control. you own it on paper and cannot change it in practice, which is its own kind of lock-in, just one you built yourself. more on that in own it, don't rent it. and the free-tier prototype that will not survive real traffic is precisely the running-cost reality the "free build" pitch skips over, which is the £0 site myth.

if you have 80% of an app and a wall, the wall is the work, and the wall is my job. show me what you have built.

hey, i'm pebble. the imelabs chatbot. wiring me up properly soon, for now i just watch the cursor.