r/lovable

Have someone else experienced a huge increase in their visitors for no apparent reason?

I went from having ~200 visitors per day to to 4k overnight. Obviously, this is a bug since my Google Analytics tells me there is the same amount as before.

Have anyone else experienced this bug?

Hi all,

I just wanted to ask if anyone’s done this successfully in their projects, I currently build my main projects on lovable for most UI tweaks etc, most code was done through codex cli and some Claude inputs, it’s all kept on my main GitHub repo. Database is hosted on supabase, auth is with clerk.

My question is, I have one app that is now live and in beta stage, I want to have a dev branch and a main branch for obvious reasons, dev branch to work on upcoming features before they’re safe, working and ready to push into the main branch. Now, I want to get this setup correctly but I’ve never been to handsy with git, could anyone work me through how I can get a dev branch working so that I could see all of my dev edits etc live on lovable, but only push the changes to the main branch once they’re verified ready?

I know and understand id need to copy the DB and input separate API keys to fully test the dev stage, but any hand holding would be appreciated to ensure I do this right, I just don’t want to mess about with the main app whilst I work on other things in the background for future updates!

Many thanks!

Hey guys, I created a virtual fortune reading website via AI lovable and would like to get some feedback to enhance the site. Do try out the 1 free full reading and compatibility reading per month using the link provided. Share with me your feedback so that I can make improvement to the site. Thanks in advance.

Hi everyone, I've built a web app completely in Lovable, and it's working perfectly. The website is fully responsive and feels almost identical to a native mobile app. Now I want to publish it to both: Google Play Store (Android) Apple App Store (iOS)

My biggest requirement is this: I want to continue building and updating the app in Lovable only. Whenever I publish changes to my web app, I want those changes to automatically reflect inside the Android and iOS apps as much as possible, without rebuilding and resubmitting the app for every UI/content update. I'm trying to figure out the best architecture for this.

I've been working on a project for a few months now and recently I've noticed my website is becoming very buggy, often I'll fix one thing and that will then 'break' something else. I chew through credits trying to fix all these bugs only for it to keep happening. Getting VERY frustrating. Is this common for Lovable? Starting to feel like I've made a mistake spending months putting this project together only for an AI platform to make it unreliable. Guh!

I’m curious how other builders here discover real problems before building a product.

Do you usually start from your own pain point, customer interviews, Reddit comments, market research, or just build and test?

I’m trying to get better at finding problems that people actually care about, not just ideas that sound cool.

Would love to hear your process.

Not a sponsored post, just an honest take from someone who's been building on Lovable for a while.

I currently have 8+ active client projects in production. A food delivery platform (customer app, restaurant app, driver app). A full chauffeur and transport ops suite. A winery e-commerce store with Spanish bank payment integration. A CRM, a hotel management system. Multiple restaurant menu platforms. A villa guest guide system. And a few more in various stages.

All solo. Based in Javea, Spain.

Here is what I have learned about why Lovable specifically makes this manageable:

The iteration speed is real. When a client has a bug or wants a new feature, the loop from "problem described" to "fix deployed" is genuinely fast. Not always first try, but fast enough that I can context-switch between projects in a single day without losing momentum.

The fact that it generates real code matters. I can read the diffs. I can catch things that are wrong. I can take a Lovable project and work on it directly when I need to. It is not a black box.

The biggest shift for me was realising that Lovable does not replace the developer thinking. You still need to understand architecture, database design, user flows, and edge cases. But it removes the part where you are fighting the tooling to implement what you already know should exist.

Could I manage this workload without it? Honestly, no. Not at this pace.

Curious what others are running in parallel on Lovable. What is the most complex thing you are maintaining?

Hi! I wanted to share a small success and my experience with no-code/low-code tools. I created https://avian-lifebook.lovable.app/ the project – an online birdwatching journal. I just passed the 1,000-user mark and I'd be happy to share what the process was like. If you have any questions about how Lovable handles more complex logic or what I found most challenging – feel free to ask in the comments! I also welcome constructive criticism.

https://preview.redd.it/wgaxgfazz68h1.png?width=834&format=png&auto=webp&s=3c15e794a4c5ee453f70a119ed76dd4dfd102e5d

So I've been working on a project for a bit and I'm at a point where I need to have the app portion I've made in lovable working outside of the lovable platform, but it's not ready to publish. (Need to do testing and while working with my hardware, I've determined the web interface is the primary source of the issues)

So while trying to build the app in Android studio, I have encountered absolutely nothing but errors. I spent all day yesterday using Gemini to try and correct the issues to no avail. I've been able to get it to the APK stage, but it just hangs on launch.

I need a better way to get this part done. Any suggestions would be great. My project is 99% through prototype at this point and once I can get it done here I can move to revision and get the hardware re-worked. But I need to make sure the app works as it should as it's kind of integral.

Hello, I’m just asking, if anyone could please join my project and provide free credit do to the simple fact of me creating an accessible version of five nights at Freddy’s four and it’s really good so far I just need the ideas and the credits. If you don’t mind providing, that would be great. Thank you.

Fresh out of the oven, so heads up if you don't see it in your account yet. Thank you Lovable team for shipping this one.

Some context on why I'm excited: over the last months I've been creating guides, skills and workflows to help builders migrate from Lovable Cloud to their own Supabase, because until today there was no official way out. Your data was basically locked in, and every migration was a hand-crafted workaround. Now there's an official path, and it's simple.

Step 1: Export your database

Go to Stack > Lovable Cloud > Advanced settings > Export data, then select "Export" in the Database card (screenshots below). You'll get a temporary download link by email. Limits: 5 GB max, one export every 24 hours.

What's actually in the file

It's a full Postgres backup (.backup file, pg_dump custom format, ready for pg_restore). And it's surprisingly complete:

• Full schema: tables, indexes, sequences, extensions
• All your data
• All RLS policies
• Database functions and triggers
• Your users: the full auth schema, including password hashes, so your users won't need to reset passwords

One warning: because it includes password hashes and user PII, treat this file as sensitive.

Step 2: Remove Lovable Cloud

Before connecting your own Supabase, disconnect the old backend: Stack > Lovable Cloud > Advanced settings > Remove Lovable Cloud.

Just make sure you have everything downloaded FIRST: your database export and your storage files (user uploads and images live in the Storage section and are not part of the database export). Once Cloud is removed, that's your only copy.

Cloud used to be permanent once enabled, so having this button at all is a big shift. And if you're not ready to fully leave, you can now pause your Cloud instance instead (screenshots below).

https://preview.redd.it/trdhbhmwi1bh1.png?width=1198&format=png&auto=webp&s=cd9f2491379b22597b517297075e908eed7d9d9d

Step 3: Connect your own Supabase project

Create your Supabase project, then connect it through Connectors: pick the Supabase connector, authorize it, go back to your Lovable project and add it. This is the native integration, so your app talks to your own Supabase from here on.

If you want to double-check everything is wired correctly, leave Lovable a prompt like:

>"Review my Supabase connection: confirm the app is pointing to my new Supabase project, check that auth, database queries, storage and edge functions all work against it, and list anything still referencing the old backend. Don't change anything yet, just report what you find."

Step 4: Move the rest over

Restore the backup into your new Supabase with pg_restore, then cover the three things that don't come in the file (by design, they don't live in the database):

• Edge functions: they're in your repo under supabase/functions
• Storage files: re-upload the ones you downloaded in step 2
• Secrets and API keys: re-set them in your new project

You can finish all of this with the MCP (I'll write about that soon), but honestly, today this whole flow is easier and more intuitive than it's ever been.

Why this actually matters

This changes how I think about Lovable Cloud, and probably how you should too.

Lovable Cloud is genuinely good, and not just for small projects. Auth, database, storage, edge functions, all working out of the box with zero keys to manage. The thing that made people hesitate was never the product, it was the lock-in: once you enabled Cloud, there was no official way out. That meant choosing it felt like a permanent decision, so a lot of us defaulted to our own Supabase "just in case."

That trade-off is gone. If your project outgrows Cloud, or you need full dashboard access, or your team wants total control, you export, remove, connect, restore, done.

Honestly, I might use Lovable Cloud MORE now, not less. Knowing I can migrate later in an easy, efficient way removes the main reason I was cautious about it. Start fast on Cloud, move when (and if) you actually need to.

What's next

I tested this flow end to end, and I'm working on a skill and plugins to make the whole move even smoother, everything the export doesn't cover, automated. That plus the updated migration guide will be on my site soon, I'll share them here when they're live.

Docs: https://docs.lovable.dev/integrations/cloud#export-lovable-cloud-data

So I’m building something where essentially there will be a ton of user logs in attachments, data, clients, whatnot.. assuming for scale how maintainable is lovable cloud or should I transfer over to supabase

Is the transfer easy? Will I have to reintegrate all my databases and log sections in lovable or is it an easy switch?

I've been building a faceless YouTube channel about weird history — molasses floods, the Emu War, that kind of thing — and figured I'd share my setup since I couldn't find a clear write-up when I started.

I start by asking Claude for three historical stories that can each be told in about 15 seconds, with the narration and on-screen visuals written out for each. It gives me three ready-to-use scripts.

Then I use the /video creator skill in Lovable to build the video with Remotion. I feed it the narration and scenes from the script and it assembles the whole thing.

The step I didn't expect to need was reviewing it. I use a /watch skill for Claude that lets it actually see the video — it pulls the frames and the transcript — so I can send the finished MP4 back and get real feedback before posting. That saved me on the first render: it came out horizontal instead of vertical, had no audio at all, and some text was cut off at the edges. I fixed those in Lovable, re-rendered, and the second version came out right.

A couple of things I learned: history is a great niche because you can use public-domain imagery and avoid the copyright strikes that hit music-based channels. And don't trust the AI on facts — it'll give you wrong dates and numbers that sound convincing, so I verify everything first and have it write around what I already know.

It's basically free if you stick to the free tiers and use CapCut for cleanup. Happy to share the exact prompts if anyone's interested.

I've been doing complimentary tech consulting calls with vibe-coders the last week. And I've noticed something:

• 70-80% of the people I've talked to are overbuilding.

Their apps/platforms are sprawling bigger and bigger: more features, more ideas, etc. And most of them still say, "I just have a few more things I'm going to add before I launch."

It's clear: one huge downside of vibe-coding is that it's so easy to just keep building. Not just easy, but addicting.

After 25 years of building and delivering SaaS products, let me tell you: more is not better. You think it is, but it's not. You don't need more features to succeed.

My calls this week were supposed to center on addressing vibe-coder's technical questions and roadblocks. But mostly I found myself giving the same advice over and over again:

You need to go narrower. You need to find the core value of your product, strip everything else away, and absolutely nail the user journey to receiving that core value. Users will land on your site/app with the assumption that they're going to be disappointed. That's the truth.

Within seconds, you have to show them something that creates a crack in that assumption. They have to react with, "Oh wow, maybe this thing is actually exactly right for me!"

Once they are open to that possibility, then you need to deliver on that promise as quickly as possible. You have a few minutes and a few clicks to do that.

That motion of "land -> overcome doubt -> deliver value" needs to be your sole focus. Strip everything else away, stop building, and start testing that flow with real users. You underestimate how hard it is to get that right, and how many iterations you need to get there. Everything else is a waste of time right now.

If you can't stick the landing on that simple flow, more features only makes it worse.

Once you get the core flow working, then you can look at adding adjacent value, features that will keep them coming back again and again, etc. You can add breadth and depth, but you won't know how to do it effectively until you've nailed the narrow flow.

Hi everyone,

I’m currently building a SaaS application with Lovable and Supabase.

The idea didn’t come from a random startup concept. It came from a real business problem.

In my own work, I’ve had to deal with inventory management in the field. And very often, when you look for a solution, you either end up with messy Excel spreadsheets, or with full ERP systems that are powerful but heavy to configure, slow to set up, expensive, and sometimes completely oversized for a small business.

The problem is that between “I write everything down manually” and “I deploy a full ERP”, there is often a missing middle ground.

I wanted an app that does one thing well: help a small business know what it has in stock, where it is, what came in, what went out, and keep a clear history of movements. Without three weeks of setup. Without confusing menus. Without an interface designed only for large companies.

The basic idea of the app is simple: connect physical inventory to a digital app using internal QR codes.

A company creates its items, prints QR code labels, and sticks them on bins, shelves, boxes, products, or storage areas. Then, when someone scans the QR code with a phone, tablet, webcam, or handheld scanner, they land directly on the item page. From there, they can record a stock entry, stock exit, inventory count, check the history, or prepare material.

The important point is that the QR code stays internal and clean. It does not contain the price, supplier, current stock, EAN, or any sensitive data. It is only a stable link between the physical item and its page in the app. If the label is damaged, it can be reprinted. If the price changes, the QR code does not change. If the supplier changes, the QR code does not change.

The other strong idea is the participative EAN / GTIN feature.

I want the app to help recognize a product when scanning a standard barcode, but without forcing companies into a rigid shared catalog. Each business must keep its own names, internal references, habits, and storage locations. The shared database should only help save time, for example by suggesting a generic product name, brand, or public manufacturer reference. It should be optional, disabled by default, and limited to public product data only. No internal business data should ever be shared.

The main target is not large companies.

I’m mainly thinking about freelancers, micro-businesses, small companies, tradespeople, small field teams, workshops, maintenance companies, construction businesses, small warehouses, and local stores. People who have a real inventory need, but not always the budget or the time to set up a big ERP.

The goal is to release a first usable version around September 2026, with a first beta release around mid-August if everything goes well.

The version I’m aiming for should allow users to manage items, QR codes, label printing, field scanning, stock entries and exits, inventory counts, movement history, material preparations, simple receptions, low-stock alerts, exports, and backups. I also want the app to work with standard handheld scanners that behave like a keyboard, because in the field, that is often the most reliable setup.

I deliberately want to keep the logic simple: no full purchasing module at the beginning, no supplier price comparison, no hidden ERP. Suppliers, purchasing, external APIs, and more advanced features can come later. The core product must first be solid: items, QR codes, scanning, stock, and history.

On the security side, I also want to start with clean foundations. Since this is a SaaS app, each company must have its own isolated data, user permissions must be respected, QR codes must not expose sensitive information, and stock movements must be historized. The idea is not just to hide buttons in the UI, but to have real data separation on the backend.

On pricing, I want to stay consistent with the target users.

Many small businesses do not want, or simply cannot afford, to pay hundreds of euros or dollars per month just to manage a simple inventory. So my current idea is to offer a limited free plan, for example up to 50 items and one location. That should be enough to test the tool, start properly, or manage a small stock.

Then paid plans would allow users to go further: more items, more users, multiple locations, more history, more exports, more advanced backups, and eventually more advanced features.

I’m also thinking about keeping some advanced features outside the free plan, especially AI features such as OCR, automatic document analysis, smart import from photos or PDFs, etc. These features can be useful, but they are more expensive to run and are not essential for the basic need.

The idea is not to charge a lot for nothing. The idea is to have a genuinely useful free version, then reasonably priced paid plans for small businesses that want to use the app more seriously.

I’m using Lovable to speed up frontend development, with Supabase behind it for authentication, database, and security.

I’d be curious to get your feedback.

Does this “simple, field-first, affordable” approach make sense for freelancers, micro-businesses, and small companies? Does a free plan limited to 50 items and one location sound relevant? When would you start charging: number of items, number of users, number of locations, advanced features, or AI usage?

I’m also interested in feedback about the field UX: QR scanning, EAN scanning, phone, tablet, webcam, handheld scanner, label printing, etc.

And if anyone here matches the target audience or would like to test this kind of tool, I’d be happy to get in touch with future beta testers. First tests should arrive around mid-August if development keeps moving as planned.

My goal is to build an inventory tool that is simple, clear, and affordable. Not a bloated system. Something small businesses can understand quickly, actually use, and keep using over time.

Thanks in advance for your feedback.

PS: English is not my native language, so this post was translated with AI. Sorry if some phrasing sounds a bit unusual.

I built a fairly niche web app for the sector i work in, basically for managing a very specific case management workflow. I was hoping it might get me a nice bit of side income. I had no experience in developing anything like this, but knew what users needed and used lovable and claude. It gives three free cases as a free trial after which its 99 a month as a subscription or 1000 for a year.

It's kinda taken off more than expected. I got to about 4k a month revenue and hired someone to migrate it off lovable and basically manage it and clean it up a bit.

Last month it hit 31k revenue, and too many users. I still have a day job which i think i need to quit!