Why Your AI-Generated Apps Break (And How to Fix Them)

Here's a scenario that's becoming weirdly common: You use Claude or another AI coding tool to build an app. It works perfectly on your machine. You add a few features, test some edge cases, maybe even show it to a friend—and then you try to deploy it to production and everything explodes.

Developer Leon van Zyl has seen this pattern play out dozens of times with what he calls "vibe coders"—people using AI to build apps without necessarily understanding the underlying architecture. In a new video breaking down production-ready tech stacks, van Zyl argues the problem isn't the AI tools themselves. It's that these tools make choices that work great for demos but terrible for real applications.

The SQLite Trap

The most common failure point? Data persistence. Van Zyl walks through a simple bookmark app to illustrate. You build a UI, it looks great, but when you refresh the page, all your data disappears. So you ask your AI agent to fix it.

First, it might suggest browser local storage. That works—until you open the app in a different browser or on your phone and realize your data only exists in that one browser session. So you ask for a proper database.

"You might have heard of SQLite," van Zyl explains in the video. "This is a tiny little database that gets created within the folder of your project and then all the data will be stored in that file instead."

Problem solved, right? The app works locally. Data persists across browsers. But you've just walked into what van Zyl calls "the trap that I see a lot of vibe coders step into."

SQLite is what experienced developers use for throwaway prototypes—proof-of-concepts they plan to delete or migrate before production. But AI agents don't tell you that. They just give you what works right now.

When you try to deploy to Vercel or Netlify, you'll discover these platforms don't allow SQLite databases in your project folder. They're designed to execute code, not store persistent data. Every time your server restarts, your database resets. All your users' data: gone.

The Backend Nobody Told You About

Here's where it gets interesting. To make that SQLite database work, your AI agent had to create something else you probably didn't understand: a backend server.

Van Zyl uses a restaurant analogy that actually makes sense. Your frontend—the UI—is the dining room where customers sit. The backend is the kitchen where the actual work happens. You don't want customers wandering into the kitchen, and you definitely don't want your UI connecting directly to your database.

"The data that we store in this database could be very sensitive," van Zyl notes. "This could be like user information. It could be passwords. It could be whatever. And we do not want anyone who's got access to our UI to have some sneaky way of getting into the database."

So now your simple React app has become two things: a frontend AND a separate Express server. You need to run both. You need to manage environment variables differently for development versus production. You need to make sure your UI knows where to find your backend. Tools like Bolt and Lovable handle this by offloading backend work to Supabase, but van Zyl argues that managing frontend and backend separately "can really be tricky."

His solution? Next.js—a framework that handles both frontend and backend in one integrated package. After migrating his demo app, the improvements are obvious: no separate server file, simplified dependencies, one command to start everything. "The frontend and the backend just talk to each other," he says. "It just works out of the box."

The Documentation Paradox

Van Zyl's advice for vibe coders might seem contradictory: Learn the tech stack, but also use AI to help you learn it. He's adamant that people actually read the documentation—Next.js docs are "complete and actually really easy to read"—but also suggests using AI agents as teaching tools.

"These coding agents are phenomenal teaching tools," he explains. "Simply open up something like Claude Code and ask it to explain the tech stack and everything that's going on in layman's terms."

This gets at something interesting about the current moment in software development. AI tools have made it possible for non-programmers to build functional apps, but there's a knowledge gap between "it works on my machine" and "it works in production." The solution isn't to abandon AI coding—it's to understand just enough about the architecture to make better decisions upfront.

Van Zyl's specific recommendation: Start with one tech stack (he advocates React + Next.js + Postgres + Drizzle ORM) and get really good at it before exploring alternatives. The temptation is to see someone using Svelte or Astro and want to try that too, "but it just feels completely overwhelming when you do that."

The Production Prompt

The video includes one practical tip that's almost too simple: Tell your AI agent you're building for production from the start. When van Zyl tells Claude he needs to deploy the app, Claude immediately changes its recommendations—ditching SQLite for Postgres with a proper ORM layer.

AI agents optimize for the constraints you give them. If you don't mention deployment, they'll give you whatever works fastest locally. The hidden cost of that convenience shows up later when you're trying to migrate a SQLite database to Postgres while your app is already live.

Van Zyl offers a boilerplate template to skip these problems entirely—a starter kit with Next.js, Postgres, Drizzle ORM, and BetterAuth already configured. It's the tech stack equivalent of "here's one that actually works, now build on this instead of debugging database migrations at 2 AM."

The real insight isn't about any specific framework. It's that AI coding tools have made building apps dramatically easier, but they've also made it easier to build the wrong thing. A prototype that works perfectly in development but fails in production isn't just frustrating—it's teaching you the wrong patterns.

Maybe the question isn't whether AI can write production-ready code. It's whether we're asking it the right questions.

— Tyler Nakamura