Published July 29, 2026 · Kiyansh Group
AI app-builders like Lovable, Bolt, and v0 are genuinely good at one thing: turning a description into a working screen in minutes. The trouble starts when a founder shows that screen to a customer, gets a yes, and assumes the hard part is done. It isn't. The prototype is the demo; the product is everything the demo quietly faked.
Talk to us about staffing →These tools are excellent at the presentation layer. They scaffold a clean component tree, wire up routing, produce responsive layouts, and generate plausible sample data so the whole thing feels alive. For validating an idea, pitching an investor, or aligning a team on what to build, that speed is real value and you should use it.
They also get you a surprising amount of correct plumbing: a sensible file structure, a modern framework, working forms, and often a Supabase or Firebase connection that stores real rows. A non-technical founder can get from idea to clickable app in a weekend, and that used to take a contractor two weeks. None of that is fake. It's just incomplete in ways that don't show up until real users arrive.
Authentication is usually the first illusion. The generated app often has a login screen that checks a password on the client, or uses the database's default policies that let any logged-in user read every other user's rows. Authorization — who is allowed to do what — is rarely modeled at all, because the prototype only ever had one user: you.
Data integrity is the second gap. There are no migrations, so every schema change is a manual edit that can silently drop a column or orphan records. There's no validation on writes, no foreign-key discipline, and no transactions, so a half-finished operation leaves the database in a state no one designed for. Add to that the missing pieces that never make it into a demo: real error handling, structured logging, rate limiting, input sanitization, secrets kept off the client, and any automated tests. The app works perfectly until the first user does something you didn't click through yourself.
Rescuing a prototype follows a predictable order, and skipping ahead is how teams get burned. First, put real authentication and authorization in place — server-verified sessions and row-level access rules — because everything after this assumes you know who is calling. Second, lock down the data layer: introduce migrations so schema changes are versioned and reversible, add validation and constraints, and move any business logic that lives in the browser to the server where users can't edit it.
Third, make failure visible and survivable: real error handling, logging you can search, and monitoring that pages someone when writes start failing. Fourth, add tests around the flows that touch money, permissions, or customer data, so the next change doesn't quietly break the last one. This is unglamorous work and it's exactly the work the builder skipped. Done in this order, a prototype becomes something you can put a paying customer's data into without lying awake.
Not every prototype is worth hardening, and pretending otherwise wastes months. The honest test is the data model and the boundaries. If the schema roughly matches how the business actually works and the app has some separation between UI and logic, you refactor — keep the frontend, replace the auth and data layers underneath it, and tighten as you go. Most well-scoped prototypes fall here.
You rebuild the core when the generated code has business rules smeared across dozens of components, a data model that fights the real domain, or a security posture so open that fixing it means rewriting every query anyway. In those cases the prototype's real value was never the code — it was the clarity about what to build. Keep the design and the validated flows, throw away the internals, and build them properly. Knowing which situation you're in is a thirty-minute code read for an experienced engineer, and it's the cheapest decision you'll make on the project.
For an internal tool or a tiny pilot with users you trust, sometimes. For anything holding customer data, payments, or accounts, no — the default auth and data-access rules usually let any user reach any other user's data, and there's no error handling or logging when something breaks.
For a well-scoped app it's typically one to three weeks: auth and authorization first, then migrations and server-side validation, then error handling, logging, and tests around the critical flows. A tangled data model or client-side business logic pushes that longer because you're partly rebuilding the core.
Usually not the part that matters. The UI, the layouts, and the validated user flows are keepers. What gets replaced is the invisible layer — auth, data access, and logic — which is the part the builder never really wrote for production in the first place.
If you've got a prototype that customers like and you're not sure it's safe to ship, Kiyansh Group can read the code, tell you honestly whether to refactor or rebuild the core, and harden it for production.
Start a conversation →