Taking a Lovable or v0 MVP to production: what AI didn't build

Short answer: to make a Lovable or v0 app production ready, stop testing the happy path and audit what the demo never showed: empty, loading, error and offline states, real data, design drift between screens, interface text, onboarding, accessibility, perceived speed and trust details like pricing and permissions. Then cut what shouldn't exist. AI built the visible 20%. This guide is about the rest.

Why does my vibe-coded app look generic or cheap?

Founders bring me weekend MVPs that are beautiful and identical. That isn't a flaw of Lovable or v0 as such. The model fills every decision you didn't make with the internet average, and it doesn't remember what it chose yesterday, so screen five slowly drifts away from screen one.

"Cheap" rarely comes from the visual style. It comes from small inconsistencies people can't name but feel: two button styles for the same action, a spinner on one screen and a skeleton on the next, an error written in a different voice. Each one is minor. Together they say that nobody owned the product.

A demo works once. A product works when you're not there

An AI demo has to work once, while its author is in the room and knows where not to click. A product has to work when nobody is around: an empty account, a 40-character name, a connection that drops in the middle of a payment.

AI made the first 20% almost free, the part you can see on a call. States, empty screens, edge cases and "the fifth screen with different rules" did not disappear. They used to hide behind a slow first step. Now the first step takes an hour, and all of that work shows up at once.

The production-readiness audit

I build in Lovable, v0 and Cursor myself, and this is the list I run before I call something a product. Most rows take ten minutes to check. Fixing takes longer, but you will know exactly where you stand.

The rest of this article covers the rows that need more than one line.

States are the product

Every action that talks to a server has at least three outcomes: it's loading, it worked, it failed. AI tends to build the second one. The other two are where users decide whether to trust you.

The empty state deserves special attention. It's the first screen every new user sees and the one founders see least, because their own account is full of test data. An empty screen is the best moment to explain value, not a place for "No items yet".

How to stop design drift: write your decisions down

The model starts every request from zero. Without written rules, you get a slightly different product every day. In April 2026 Google Stitch open-sourced DESIGN.md, a Markdown file in the repository where you describe your design rules so agents read them before building.

A useful DESIGN.md covers tokens (color, type, spacing, radius), components and when to use each, how empty, loading and error states look, how the product talks, and what it never does. Taste became a file. But you can only write down what you already decided, so the file is the result of design work, not a replacement for it.

UX copy: write it last, check it first

AI writes interface text that is correct, smooth and faceless. I used to think text was a detail, until metrics showed me that one phrase on a button moved conversion more than a redrawn screen.

A good button says what happens next: "Send request, we reply within a day". "Something went wrong" is the most honest sentence a product can say about not having thought of the user. Rewrite every error to answer two questions: what happened, and what do I do now.

Speed people feel

Users don't experience your load time in milliseconds. They experience waiting. Jakob Nielsen's three response-time limits still hold: about 0.1 second feels instant, about 1 second keeps the flow of thought, and at about 10 seconds people lose attention and need progress feedback. Show the page shell first, load content into it, and keep buttons responsive even when the server isn't.

Trust: pricing, payments, permissions, data

Trust is mostly made of boring details. Before someone pays, they want to know the price, what's included, when they'll be charged and how to cancel. Before a mobile app asks for location or notifications, people want a reason, in context, at the moment it matters.

Data is part of trust too. In 2025 a researcher found 303 vulnerable endpoints across 170 Lovable projects with missing or weak row-level security, logged as CVE-2025-48757. That's an engineering fix, but it's a product decision to check it before launch.

What to cut before launch

After a month of building a product with AI, I noticed it never once told me "this is a bad idea". In a team there used to be resistance: a designer would say people won't get it, a developer would say it's too expensive. AI gives you execution, not resistance. A bug crashes and you see it. A bad decision built well looks like progress.

So I cut about a third of what I'd built over a weekend. The product didn't shrink. It came together. My filter for each feature:

• Does it help someone reach the first useful result?
• Would anyone notice it missing in the first week?
• Is it here because users need it, or because it was easy to generate?

Why I build the first slice myself

I used to hand off mockups. Now I build the first working slice in Lovable, v0 or Cursor. A mockup never pushes back. A built screen pushes back right away: a state I didn't think about, a two-second load, real text that doesn't fit. A developer used to find these a week later, as revisions. I find them within an hour, while they're still decisions. I didn't become an engineer. I became a designer to whom reality answers immediately.

When to bring in a designer, and what to ask them

Bring in a product designer when the prototype works but looks cheap, when people sign up and drop off in onboarding, when every new feature feels like a separate app, or before you show the product to investors or paying customers.

Questions worth asking in the first call:

1. "What would you remove from this?" A good designer has an answer, with reasons.
2. "Show me the empty, loading and error states you'd design for our main flow."
3. "Can you work directly in our Lovable project or repo, or only in Figma?"
4. "How will the AI tool stay consistent after you leave?" Listen for a design system or DESIGN.md.
5. "What would you check first in our onboarding, and why?"

When I interview designers, I care less about the tools they know and more about what they reject and why. Same prompt, same result. Judgment is what you are paying for.

FAQ

How do I make my Lovable app production ready?

Run an audit beyond the happy path: empty, loading, error and offline states, real data, consistency between screens, copy, onboarding, accessibility and payment flows. Have a developer review database access rules. Then cut features that don't serve the first useful result.

Why does my v0 or Lovable app look generic?

The model fills every unmade decision with the most common pattern and doesn't remember earlier choices. Write your rules into a design system or DESIGN.md file and make one clear visual choice instead of accepting the defaults.

Should I hire a designer or a developer to fix my vibe-coded app?

Usually both, for different problems. A developer fixes security, data and performance. A product designer fixes states, flows, onboarding, consistency and what the product should and shouldn't do.

Can I keep building in Lovable after a designer polishes the app?

Yes, if the designer leaves written rules behind: tokens, components, state patterns and voice. Without them the next prompts will drift back toward the average.

---

Alla Kuchynskaya is a Senior Product Designer and AI Product Builder with 12+ years in startups, who builds working MVPs in Lovable, v0 and Cursor herself. She led UI for VOCHI (App of the Day in 126 countries, acquired by Pinterest) and redesigned onboarding and core flows at Findmykids (55M+ downloads, +18% retention). She works part-time, full-time or per project, remotely from Bali. Portfolio: alla.studio · Telegram: @aladesigner.