To anyone using AI site/app builders (Lovable, v0, Bolt, etc.): What’s the biggest technical debt / performance wall you’ve hit?
Hey everyone! I’ve been analyzing a few sites generated by modern prompt-to-code builders (v0, Bolt, Lovable, etc.) lately from my clients. While the visual UI output is impressive, I’ve noticed a recurring theme when it comes to actual production readiness…
Hey everyone! I’ve been analyzing a few sites generated by modern prompt-to-code builders (v0, Bolt, Lovable, etc.) lately from my clients. While the visual UI output is impressive, I’ve noticed a recurring theme when it comes to actual production readiness specifically around Core Web Vitals, SEO indexing, and overall page performance. A lot of these engines seem to dump heavy JS bundles, default to client-side rendering without proper metadata/OG setups, or struggle with hydration overhead once the app grows past a few pages. For those of you building or launching projects with these tools, my questions are: What’s your average Google PageSpeed / Lighthouse score once you actually deploy to production? Have you run into SEO / indexing issues with Google crawlers due to client-side rendering? How bad is the code regression? (e.g., asking the AI to fix a small layout bug on one page, only for it to break routing or component state on another page?) If you had to export the code and fix it manually, what was the biggest bottleneck to clean up? Curious to hear what walls you’ve hit once you move past the initial "wow" factor of generating a layout.
已收录讨论
The biggest wall I’ve hit is code regression. A small request like changing a component layout can sometimes make the AI rewrite shared components or routing logic, causing bugs in places that were already working.
Do you find this happens more when you prompt in plain English vs specifying the exact component file name?
这条评论已被删除。
Yeah and the migration is what actually kills the timeline. By the time someone asks for help the data is already sitting in those tables, so you cant just fix the schema, you have to move real rows into a new one without losing anything. Cheapest fix early on is to decide your core tables by hand before you let the tool touch anything. Users, orgs, whatever the main object is. It still makes a mess around the edges but the middle stays sane.
Yeah, asking for a simple UI tweak only to realize it created another user table with duplicate data is painful. Cleaning that up takes longer than building it manually.
The tell is when two tables both have an email column and neither one is the source of truth. At that point its a data migration, not a cleanup, and thats where the week goes.
Regression is the one that costs real money and its structural, not random. These tools have no concept of a module boundary, a shared component is just text that shows up in a lot of files. Ask for a padding change on one page and it rewrites the thing five other pages import. On perf the bundle isnt really the killer. Its that everything defaults to client side, so you end up shipping data fetching to the browser and then waterfalling it. Thats not a cleanup pass, thats a rewrite of how the pages load. Every time ive taken one of these over the actual time sink was the backend anyway. No data model. Tables invented per feature, same thing stored three ways, no constraints. Any real fix needs a migration before you touch the ui.
The back-end point is huge and almost nobody talks about it. Everyone focuses on how fast the UI generates, but behind the scenes the AI just hallucinates a new unconstrained database table for every single feature prompt. You end up with 15 duplicate tables, zero relational integrity, and total chaos the second you need a real SQL migration. And spot on with the client-side data waterfalls defaulting to client fetching destroys both execution speed and user experience. I appreciate you highlighting the database debt side of this!
The regression part is the one I’d watch first. I’d test it with one tiny change after the first deploy, not just the first build.
The pattern I've seen most with v0, Bolt and Lovable output: they are optimized for the first deploy looking great, not for what happens after month two. Client side rendering by default is the biggest one, it looks fine in a demo then tanks Lighthouse and indexing once Google actually tries to crawl it. The other one is prompt driven fixes causing regressions elsewhere, because the model does not really understand the full component tree, it just pattern matches the file you pointed it at. Exporting the code and doing a proper pass on routing, metadata and hydration usually fixes most of it, but people underestimate how much that pass costs in time. There's a second kind of debt that tends to show up right after the technical one gets fixed though: operational debt. Once the site performs and people start signing up, you suddenly have real customers, contracts, invoices and support requests with nothing connecting them, because none of that was part of the original build. Disclosure: I build Base (withbase.ai). It's aimed at exactly that second problem, connecting CRM, contracts, invoicing and the rest for founders who just got a site like this into production and now need to run the business behind it.
The SEO/indexing side of this doesn't get talked about enough, and it's honestly worse than most people think. We audited a client's Lovable-built site a few months back, and the biggest issue wasn't Lighthouse score, it was that Google could eventually render the JS-heavy pages (slowly, not always reliably), but a lot of AI crawlers don't render JavaScript at all. If your content depends on client-side rendering, delayed hydration, or fetching data after the page loads, tools like ChatGPT's crawler or Claude's crawler may just never see it, even though it looks completely normal in a browser. That's a different failure mode than classic SEO indexing, and it's easy to miss because the page looks fine when you check it yourself.