How I Built the LAB (And What I Learned About Vibe-Coding That’ll Save You Money and Time)

What no one tells you about building apps with AI: my real learnings, the things I wish I knew before I started, and the prompts that will save you money and frustration

I get a lot of questions about how to build with AI, which makes this article long overdue. So today I want to share everything I wish someone told me before I began building my own projects, and a few things I think will help if you’re just starting.

---

One of my readers, Sid, asked me pretty recently: “Are you planning a post on how to create a website and have it continuously updated with AI? I’ve been trying to get a website going but it’s been hard the traditional way. I bet it’s easier with AI.”

If you are building a simple landing page, the easiest starting point is this article I wrote a while ago.

The Secret’s Out: How to Build a Website in Minutes for Less Than $5

Landing pages are usually straightforward. You describe what you want in plain English, pick a visual style, maybe let an AI model refine it, and you get something usable in just a few minutes.

But this article is not about that.

Today we are diving into more complex projects, because things change completely once you move from a simple page to an actual platform. That is where the real challenges start showing up.

Kim Doyal, who is already building a lot of awesome products, told me: “I started on Lovable, got really close to something finished, and ended up stuck in a loop of the same errors.”

And she is not the only one. Once you go beyond a landing page, the questions, the errors, and the decisions start piling up.

You hit bottlenecks, and if you are not technical, it becomes hard to figure out what is going wrong. You cannot tell where the issue comes from and you do not think the way a developer would.

You look at the feature as a user, not as someone thinking about data, flows, or system behavior. And the more moving parts you add, the more fragile everything becomes.

So in this article, I want to walk you through what I learned building AI blew my mind LAB and from vibe-coding in general as a non-technical person, which I know is the case for many of you too.

By the end, you’ll understand the parts of the process that actually make building platforms with AI doable end to end, without burning time, money, or getting stuck — the things I had to learn the hard way and rarely see anyone talk about.

If you are new here, the LAB is our hub of guides, automations, and prompts that help you integrate AI into your workflows and build systems that support your work, your career, and your business. It has resources for every role, in any industry. Check it out.

Learning 1: Speed becomes a trap when your idea is still liquid

The problem

You start building before you know what you want.

Back in June, that is exactly what happened when I tried to build the first version of the LAB. I fell right into the mistake I always tell people to avoid.

I didn’t make up my mind before opening Lovable and jumping straight in. I kept improvising features, changing layouts, and stacking ideas on top of half-decisions. A new tab here, a filter there, another section because “maybe it’s useful”. One fix broke something else. Then fixing that broke something else again.

Eventually, rebuilding from scratch became cheaper than trying to save it…

The thing with AI tools is that they make it so easy to start building that you skip the thinking that used to be unavoidable before AI. And in the rush we’re all moving in, it’s easy to overlook that clarity is still a human job, and AI can’t shortcut that for you.

Back when we were building DO-IT a few years ago (and we didn’t have AI to help), the story was different. We mapped everything in Miro. Screens, interactions, user paths. It took days, but it kept us on the right path.

Now we don’t need to map everything for days the way we used to. We can start building much faster.

But we still need a moment of clarity before we dive in, unlike I did the first time.

Simple landing pages can survive a bit of chaos, but anything more complex can’t. Once your project has user states, different content types, conditional logic, an admin view, or data relationships, a tiny shortcut can become a real bug later.

The solution

Pay the clarity tax upfront.

Slow down long enough to figure out what you’re actually building. Outline the features, flows, and the order in which things should work. Build one working piece at a time.

AI will always let you start over. But if you skip clarity at the start, you’ll pay for it later in time, credits (which is basically your money), and frustration.

So before you start building your next project, use this prompt with Claude, ChatGPT or Gemini. You can find it in the LAB:

Clarify your app idea, user flow, and MVP before you start vibe-coding with AI

---

Learning 2: Start with backend logic, then admin, then frontend

The problem

You don’t know how the pieces fit together.

When you are building with Lovable (or any vibe-coding tool) and you don’t have technical knowledge, everything feels like ‘frontend’ because that’s all you see.

You see the page, the buttons, the layout. You don’t see the structure that actually makes the whole thing work.

It’s like going into a restaurant and only seeing the menu and the dish, not the kitchen, not who’s cooking, not the recipe, or how it even came together. But underneath, there’s a whole structure that still needs to make sense.

If you don’t understand how your data flows and connects, you’ll build features that contradict each other or force big and expensive database changes later.

The solution

Lovable now builds most of the stack for you. When you ask for a feature, it sets up the backend first and then generates the frontend on top of it. You don’t have to wire those parts manually.

But your mental model still matters. Lovable usually keeps the backend and frontend in sync automatically, but the admin layer isn’t always included by default.

It might add a new feature to the frontend and it might create the data structure for it in the backend, but it won’t add the matching admin tools unless you tell it to.

For example, if you introduce something new - like a resource card - remember it should exist in all three places: it shows up on the frontend, it’s stored in the backend, and in the admin, you need to ask for a way to create, edit, or delete resources.

If you understand how your data works across these layers, your prompts make sense, your features don’t contradict each other, and you avoid painful database restructuring later.

To understand these layers in your own project, use the prompt I added in the LAB:

Map out backend, admin, and frontend before you start building a website with AI

---

Learning 3: Prompting is everything, but you don’t have to do it alone

The problem

Your prompts are too vague or assume the tool knows what you mean.

Take my case: when I added user activity info to my LAB admin dashboard, I didn’t explain how I wanted the layout to look. Lovable guessed and built its own version, which wasn’t helpful. And fixing it after that was harder than just being clear from the start.

The thing is, Lovable can build almost anything. It just needs you to point it in the right direction.

A vague prompt gives you vague features. A specific prompt gives you exactly what you need, faster, with fewer edits, fewer credits, and less frustration.

The solution

Learn to prompt better and use AI to help you prompt.

Many people do not know this, but Lovable has their own official Prompting Guidelines and a Prompting & Debugging Playbook you can use. There is no better way to improve your prompts than to start from the best practices they already share.

But reading long documentation while you build can be tedious, so I made this easier:

I built a CustomGPT trained on the official Lovable playbook that gives you Lovable-ready prompts without guessing (both for building and debugging): The Lovable Prompt Architect.

If you want to see the full behind the scenes of how I built it, I added a step by step guide inside the LAB for premium subscribers (including the exact instructions I gave it and the full knowledge base I uploaded):

How I built the Lovable Prompt Architect CustomGPT (behind the scenes).

If you prefer staying inside your workflow while you build, another way to use the official Lovable guidelines is with AI-assisted browsers like Comet or Atlas.

Keep Lovable open in one tab and the guidelines in another, and ask the browser AI to read both and help you shape the prompt before you paste it into Lovable.

The main idea to keep in mind is simple.

For small UI tweaks or layout changes, you do not need anything prompt-heavy. Write the prompt yourself as long as you are clear about what you want.

For bigger changes like new features, logic, the first prompt of the project, or debugging something messy, let ChatGPT, Claude, or Gemini structure the prompt for you before you send it into Lovable, or use my CustomGPT.

It reduces mistakes, saves credits, and keeps your project cleaner, especially when you do not have strong prompting skills or technical knowledge.

---

Learning 4: Examples beat descriptions for UI

The problem

You describe what you want in words and Lovable builds something completely different from what you pictured in your head.

Or maybe that’s not even the issue. Maybe the problem is that the design it generates looks the same as every other design you see everywhere (because it falls back on the same generic design patterns), while you want something else.

The solution

A picture is worth a “thousand tokens”.

When you show Lovable a reference image, it instantly understands the visual hierarchy and layout, the spacing and proportions, the style and aesthetic, the interaction patterns, the level of polish you’re aiming for.

This eliminates dozens of back-and-forth edits trying to explain what you mean by ‘modern’ or ‘clean’ or ‘professional’, or how the whole layout should look.

When I built my first startup (DO-IT), we spent days researching other products and screenshotting patterns we liked.

You don’t need that level of research today, but attaching references still makes the build so much easier.

So this time, from my very first prompt building the LAB, I added a reference.

And whenever I wanted a specific look for a feature, I’d attach a reference and tell Lovable how to adapt it while keeping my colors and style. It always gave me better results with fewer edits.

Where to find inspiration:

• Browse other apps or platforms

• Search Dribble and Behance for UI examples

• Sketch your own ideas and drop them into Nano Banana Pro to generate a design, and if you like that result, attach it directly into Lovable

---

Learning 5: If something fails twice, stop brute-forcing it. Change the approach.

The problem:

You can’t get a new feature to work or fix a bug, no matter how many times you try.

You tweak the prompt, then tweak it again, because it feels like you’re “almost there”.

And sometimes it is the prompt. But when something fails multiple times, that’s usually your sign that the approach itself needs to change.

I hit this myself when building the LAB. Some resources are free, some are paid, and I wanted a Substack-style preview for premium ones: free users see a teaser and an upgrade banner, paid users see the full content.

I tried building an actual paywall, just like Substack has. It didn’t work. I lost count of how many times I retried it, convinced the right wording would eventually fix it.

But as a non-technical person, I didn’t know how to prompt it any better or what the feature needed technically, or why Lovable wasn’t handling it the way I imagined. And that can be a real bottleneck at times. No matter how many times you try to fix it, it still doesn’t work.

So when I hit that point, I change the approach.

The solution

In my case, I stepped back and looked for a different way to reach the same outcome.

I duplicated the content editor in my admin: one section for free content (visible to everyone) and one for paid content (visible only to premium subscribers). I explained the logic clearly and that solved the whole thing in no time. From the very first prompt with this new approach, it worked.

Sometimes you just need to brainstorm other ways of achieving the same outcome, either on your own or with AI. Instead of asking “How do I make this work?”, ask “What other ways could I achieve this?”

Use this prompt you’re stuck:

I’m trying to [describe what you want to achieve]. 

I’ve tried implementing it by [describe your approach], but it keeps failing.

What are three completely different ways I could achieve the same outcome? Think creatively about workarounds that might be simpler to build.

Then pick the approach that sounds most doable and try that instead.

---

Learning 6: Debugging isn’t coding. It’s reasoning expressed through prompts

The problem:

You don’t know why something broke, how to explain it, or how to make it work.

When a feature stops working, your natural reaction is: “Why is this broken?” But that’s not helpful to Lovable. It needs direction.

Technical knowledge can help with debugging, but since we don’t have that, our job is to guide the tool.

The solution

Use structured prompts that help the tool think.

Instead of “This doesn’t work”, give Lovable a clear debugging framework:

• Describe the expected behavior vs. actual behavior: “When a user clicks the save button, it should save their progress and show a confirmation. Instead, nothing happens.”

• Ask how it’s built and push it to think of other options: “What have you set up so far? What haven’t you tried yet? What else could you try that you didn’t already?”

• Point to recent changes: “This worked before I added the new form fields. Could those be interfering?”

• Request step-by-step thinking: “Walk through what should happen when this button is clicked, and identify where the logic might be failing.”

You can even use the chat mode in Lovable to brainstorm possible fixes before spending credits implementing them, or use my CustomGPT.

---

Lesson 7: Protect your build from accidental regressions

The problem

New features break old features.

You add something new or fix a bug and suddenly a feature that was working perfectly yesterday is now broken. Lovable doesn’t announce “Hey, I also changed that other thing.” You only discover it when testing.

This is perhaps the most frustrating part of building as your project grows more complex.

But it does happen, because every new feature increases the risk of unintended consequences. And as your platform grows, everything becomes interconnected.

A change to your user authentication might affect how resources display. A new filter might break your search functionality. A style update might mess up your mobile layout. You… never know.

The solution

Explicitly protect your existing build in every prompt.

Add this line to EVERY prompt when working on established projects:

Implement the [specific feature/fix] while ensuring core functionality and other features remain unaffected. Evaluate its behavior and dependencies to identify potential risks, and discuss any concerns before moving forward. Conduct thorough testing to verify there are no regressions or unintended consequences. Exercise caution—pause if uncertain.

Or at least, this simpler version:

Make this change without altering any other features or functionality. Test thoroughly before implementing.

Trust me, it will save you from so much frustration.

---

Lesson 8: Sometimes the problem isn’t your prompt, it’s a technical gap

The problem

There are moments when nothing you try works. Not because you’re doing it wrong, but because the feature you’re trying to build actually needs technical thinking.

This part doesn’t get talked about enough in the AI space. We tell people “go build your own tools”, but we rarely mention that some issues simply require someone who understands how things work behind the scenes.

I hit this myself with something as simple as adding a copy button inside the code blocks where I write prompts. It looked trivial. Lovable kept failing. I tried dozens of variations. Nothing worked.

At some point, it wasn’t a prompting issue anymore. It was a technical one.

So I asked my friend Matei, who actually understands this stuff. The way he approached the feature was completely different from how I was thinking about it. After a few back and forths, he directed Lovable correctly and the issue was fixed.

The solution

Sometimes you just need a technical person to take a quick look. That’s okay.

Don’t beat yourself up for something that just needs a different type of thinking. The whole point of building with AI is to reduce the gap, not pretend the gap doesn’t exist.

Tried any of these yourself or hit similar walls? Drop a comment, I’d love to hear your experience.

Other practical tips & tricks

1. Starting your build

→ Start from community projects (if you want a head start)

If you’re just starting out, navigate to the “From the Community” section in Lovable. You can enter any project and use it as a base by remixing it and changing it. You can find solid starting points there instead of building from scratch, and it helps you save credits early on.

→ Budget for your build

I paid around $150 to build the LAB. It is a pretty complex build, so the cost makes sense, and it’s tiny compared to what I’d spend hiring a developer, a UI/UX designer, and the extra time that would come with it.

The cost really depends on how complex your project is and how well you prompt (since good prompting helps you avoid a lot of avoidable errors and bugs).

2. While you’re building

→ Make quick copy edits without prompting

To make small text edits on your website, you don’t need to prompt Lovable every time. Just click “Visual Edits”, select the area where you want to change the copy, and either prompt directly to that area or change it manually in the window. This saves you credits and time on trivial changes.

→ Use “Revert” instead of fixing a bad update

If a recent change breaks something or the output isn’t what you wanted, don’t waste time debugging it. Just hit Revert and go back to the previous working version. It’s faster than trying to fix a messy update, and it gets you back to a working state instantly.

Then rewrite your prompt with clearer instructions so Lovable gets closer to what you actually want.

→ Publish privately to test as you build

You can publish your project and keep it private while you work. This lets you test edge cases in a real environment instead of relying only on the preview. Click around, try user flows, check screen sizes, and catch issues the editor won’t show.

Just remember that every change needs to be republished to show up live.

And if your project includes sensitive work, keep it private so no one can remix or copy it:

→ Run security scans when Lovable prompts you

If your project collects user data (emails, accounts, subscriptions), this step isn’t optional. It protects both you and the people who trust you with their information. And even if you’re not handling sensitive data, ignoring security issues can let malicious users break your platform or damage your app.

It takes one minute, and it saves you from massive headaches later.

So when Lovable tells you there are security issues in your project, don’t ignore these. Just ask Lovable to fix them.

3. Finishing touches

→ Add your favicon

To add your website icon (the little image that appears in browser tabs), you need to upload the favicon in your project settings. This is a small detail that makes your project look more polished and professional.

Just prompt Lovable: “Replace the current favicon with this logo and update all pages so the new icon appears in browser tabs” and it will handle it.

→ Edit website metadata

Make sure you edit the website info (title, description, share image) in the publish settings. Lovable will generate defaults, but you’ll want to customize them.

This is what appears when you share your website on social media or in search results, so it’s worth getting right.

→ Remove the Lovable badge

Once you’re on a paid subscription, go to Project Settings and toggle on “Hide Lovable badge” to remove the “Edited with Lovable” text from your site.

This is only available for paid users, but it gives your project a cleaner, more professional look.

3. Publishing your project

→ Connect your custom domain

The “Publish” you used earlier for testing already puts your project live on Lovable’s generated URL. It’s the fastest way to share your work and see it in action.

If you want it on your own domain (like app.aiblewmymind.com), you’ll need to:

• Acquire a domain from sites like GoDaddy or Namecheap

• Add your custom domain in Lovable’s publish settings

• Approve the DNS changes from your domain provider (they’ll give you instructions)

It usually takes a few hours for the domain to fully connect.

→ Understand hosting

You don’t have to think about hosting. Lovable Cloud is enabled by default and handles everything for you, from the database to the backend. Your project just runs.

To keep your site live, you need an active subscription (starting at $20/month). And if you ever want to move your project out of Lovable later, you can do that. There’s no lock-in.

---

The bigger picture

Vibe-coding can look intimidating from the outside. It feels like everyone is spinning up apps in a weekend while you are still trying to understand what goes where.

But here’s the real story: the process used to be much longer.

If you look at the examples I shared from DO-IT, that was the reality before we had AI. Mapping screens, flows, logic, user paths… it took days just to get to the starting line.

AI cuts out a lot of the overhead, which is great, but it doesn’t replace the human part. You still need to think, to get clear, and to understand what you are actually asking it to build. If you try to shortcut that, you end up paying for it later.

So it really comes down to a few simple things:

• Get clear on what you are trying to build

• Learn to talk to the tool in a way it understands

• Notice when you are stuck on an approach and be willing to change it

You do not need to think like a senior engineer. You just need a bit of structure around how you ask, how you test, and how you recover when things break.

---

If you want more support while you build

The LAB is where I put everything that doesn’t fit into the newsletter. There are around 80 resources inside now, used by more than 250 people, and it’s a solid place to go deeper into building and working with AI.

A premium subscription to this newsletter unlocks all premium resources in the LAB. I share far more there than I can fit in the emails, simply because there’s too much to cover otherwise.

Would love to have you inside,

Daria