Last month I shipped a complete web product in two days using Lovable. Not a landing page. A working app with auth, database, payments, and a custom UI that didn't look like a template.
This post breaks down exactly how a vibecoding session works when it goes well — the prompts, the iteration loop, the mistakes, and the shortcuts that actually save time.
What vibecoding actually means
Vibecoding is building software by describing what you want in natural language and letting an AI tool generate the code. Lovable is one of these tools — it generates full React + Supabase apps from a conversation.
But there's a catch. The quality of what you get depends almost entirely on how you start the conversation.
The init prompt is everything
Most people open Lovable and type something like "make me a quiz app." That gives you a generic quiz app. No personality, no business logic, no differentiation.
Here is what actually works. Your first prompt needs four things:
1. The vibe. Not just "quiz app" but the emotional experience. "A personality quiz that feels like a magazine quiz from the early 2000s — playful, slightly irreverent, with bold typography and unexpected color choices."
2. The audience. Who uses this? "Women 25-35 who share results on Instagram Stories." This changes layout decisions, font sizes, share button placement.
3. The UX flow. Walk through the screens. "Landing → select quiz type → 12 questions with progress bar → animated results → share card → optional email capture." Don't leave screen transitions to chance.
4. The business model. "Free quiz, email gate on detailed results, upsell to premium quiz packs at $4.99." If the AI knows how money flows, it structures the database and UI around it.
One prompt. Four dimensions. The difference between a weekend project and something you can actually show to users.
The iteration loop
After the init prompt, Lovable generates a first version. It is never right. That is fine. The real skill is how fast you iterate.
My loop looks like this:
Generate → Preview → Fix one thing → Repeat.
The key word is "one thing." When you try to fix five problems in a single prompt, Lovable often breaks something that was working. Small, targeted edits compound fast.
Typical iteration prompts from my last build:
- "Move the CTA button above the fold on mobile."
- "The progress bar resets when going back. Keep state on navigation."
- "Add a subtle entrance animation to the results card. Nothing dramatic, just a fade-up."
Each of these took under 30 seconds to generate. The whole iteration cycle — from first render to something I'd show a user — was about 4 hours across two sessions.
The five traps I keep falling into
After shipping 16 products this way, I still hit the same problems:
1. Duplicate routing. Lovable sometimes creates two route definitions for the same page. Everything works until you deploy and one path 404s. Always check your router config before publishing.
2. Hardcoded copy. You describe a feature in English, and the AI hardcodes English strings everywhere. If you need localization later, you are refactoring for hours. Mention the target language in your init prompt.
3. Auth edge cases. The generated auth flow handles the happy path. It rarely handles token expiration, email not confirmed, or OAuth provider errors gracefully. Budget one iteration cycle just for auth edge cases.
4. Public Supabase buckets. Lovable defaults to public storage buckets. If users upload anything personal (photos, documents), you need to switch to private buckets with signed URLs. This is a security issue, not a convenience issue. Tools like Audit Vibe Coding can flag these automatically.
5. Missing Row Level Security. The database tables get created, but RLS policies are often too permissive or missing entirely. Any user can read any other user's data. This is the single most common security hole in vibecoded apps. Check your policies. Better yet, run an automated scan.
Shortcuts that actually help
@-reference other projects. In Lovable, you can reference other projects as context. If you already built a similar product, point the AI at it. "Use the same auth flow as @pet-imagination but with the color scheme from @party-challenges." This saves a full iteration cycle.
Use the Knowledge feature. Upload your design system, brand guidelines, or a screenshot of the UI you want to match. Lovable reads these as context and the first generation is significantly closer to what you need.
Visual Edit mode for pixel tweaks. Don't describe spacing in words. Click directly on the element and drag. Lovable translates visual edits into code changes. This is faster for layout work than any prompt.
Deploy early, iterate on production. Don't wait until everything is perfect. Publish after the first working version. Real users find problems you never imagined. And seeing your product live changes your priorities instantly.
What this actually costs
Two days of focused work. No designer, no backend developer, no DevOps. Lovable handles hosting. Supabase handles the database and auth. Total infrastructure cost: around $25/month for a product serving real users.
The trade-off is clear. You get speed and you lose control over code architecture. The generated code is functional but not beautiful. If the product gets traction, you will eventually want to refactor parts of it. But by then you have users, revenue data, and a much better understanding of what to build next.
The security gap nobody talks about
Speed comes with risk. When you ship in two days, you skip the security review that a traditional dev cycle includes. RLS policies, storage permissions, API exposure — these things slip through.
I built Audit Vibe Coding specifically for this. It scans Lovable and Supabase projects for the most common security mistakes that vibecoded apps ship with. Open storage buckets, missing RLS, exposed API keys, permissive CORS — the things that don't break your app but do expose your users' data.
If you are shipping fast with Lovable, Cursor, or any AI coding tool, a security check is not optional. It is the minimum responsible thing to do before going live.
Resources
- Vibe Codéři — Czech vibecoding community with tutorials and case studies (Czech language)
- Audit Vibe Coding — automated security scanner for AI-built apps
- Inithouse — the portfolio behind these experiments
Building products this way changed how I think about software. The bottleneck is no longer code. It is knowing what to build and having the discipline to ship before it feels ready.
Top comments (0)