I one-shotted a full SaaS in Lovable (AI agents, auth, usage gate, etc.). 3 lessons I learned ↓

I did it. I one-shotted a Lovable app - and not a simple one.

I built a branded, Netflix-style hub of AI tools for my audience. Think: a website where people land, browse a library of AI agents and workflows trained on my expertise, sign up, fill in their profile, and start using the tools - with every tool knowing who they are and personalizing its responses based on their profile. The hub handles auth, onboarding, usage tracking via webhooks, a paywall that kicks in after a free tier, full run history with resume, dark mode, and an admin dashboard. 9 pages total.

One prompt. One paste into Lovable. It just worked.

I've been trying to figure out why this one worked when my previous attempts always needed 5-10 rounds of back-and-forth. I think it comes down to 3 things I did differently this time.

1. I mapped out the full system before I wrote a single word of the prompt.

Before, I used to open Lovable and start describing what I wanted as I thought of it. "Build me a page that does X. Oh and also add Y. And it should connect to Z." That's basically thinking out loud — and Lovable builds as you think, so you end up with a Frankenstein app that half-works.

This time I sat down and mapped everything first. What pages exist. Which are public, which need login. What data I collect from users and when. Where that data needs to go. What happens when a user hits a limit. What happens when they resume a previous session. I wrote all of this down before I opened Lovable.

The prompt ended up being long - but it wasn't rambling. Every line was intentional because I'd already thought through the system. Lovable didn't have to guess anything.

If you're building anything with more than 3 pages, map your system first. Write it for a human before you write it for Lovable.

2. I described business logic, not technical implementation.

This was the big shift. My old prompts used to say things like "create a Supabase table with columns X, Y, Z" or "add a React context provider for user state." I was telling Lovable how to build.

This time I only told it what should happen.

"Users get 3 free runs per month. After that, block the tool and show an upgrade prompt. Show a counter of remaining runs in the nav at all times. When a run completes, a webhook fires - here's the payload. Deduplicate by run ID before recording. Reset monthly."

I never mentioned a database schema. Never mentioned a state management approach. Never mentioned a specific library. I described the behavior I wanted as a set of clear rules, and Lovable figured out the implementation.

This works way better because Lovable is good at choosing the right technical approach for a given behavior. It's bad at following prescriptive technical instructions that might conflict with how it prefers to scaffold things. Describe the rules. Let it build.

For anything involving access control, payments, limits, or gating - describe it as: what triggers it, what the user sees at each state, and what the edge cases are. That's it.

3. I gave a full integration contract for every external system.

This is the one nobody talks about, and it's the reason most complex apps need endless back-and-forth.

My hub embeds AI tools from an external platform (MindPal) via iframes. Each embed needs two things injected at runtime: the logged-in user's ID and their profile data as session context. There are also webhooks that fire when a user completes a run, and my app needs endpoints to receive those payloads.

In my old prompts, I would have written: "embed the tools and pass user data to them." Lovable would generate a static iframe and I'd spend 6 rounds explaining how the data passing actually works.

This time I included the full contract. The exact iframe code pattern. The exact JavaScript config block. The exact parameter names the external system expects. The exact webhook payload schema showing every field. I even included code examples with "// TODO: Replace with actual value" comments - Lovable read those and swapped them for real references to the app's auth state.

Lovable generated every integration correctly on the first pass. Not because it knows MindPal - it doesn't. But because I gave it everything it needed to wire things up without guessing.

This applies to any external integration. Embedding Calendly? Give the exact embed URL pattern and how to pass prefill parameters. Connecting Stripe? Give the webhook payload schema. Using any third-party API? Give the request/response format. Don't describe the integration in English - give the technical contract and let Lovable implement against it.

What I'd do differently next time:

Honestly, not much. The prompt was long but it generated a working app. I think people underestimate how much Lovable can handle in a single prompt if the information is structured well. The issue is never prompt length - it's prompt clarity.

If I had to boil it down: know your system, describe the behavior you want (not the implementation), and give the full technical contract for anything external. Do those three things and you'll be surprised how close to one-shot you can get.

Try my app → https://amber-mind-forge.lovable.app/

Full video walkthrough of the build →

Happy to answer questions or talk through how to structure your prompt for whatever you're building.