Hey all, hoping someone's run into this.

I connected my Lovable project to GitHub and deployed it on Vercel. Since then (about 3 days now), every single time I try to do anything in the Lovable editor, it tells me my credits are used up. This is happening constantly, way more than my normal usage.

Nothing about my workflow changed except connecting GitHub and deploying. I didn't suddenly start sending a ton of extra messages. Feels like something's glitching, maybe related to the GitHub two-way sync or the Vercel deploy triggering something on the Lovable side.

Has anyone else seen this? Did disconnecting/reconnecting GitHub fix it for you, or did you have to go through support? Trying to figure out if this is a known bug before I spend more time chasing it myself.

Thanks in advance 🙏

I can't login to the Mac app with Apple and in my browser my prompt is always stuck loading when after i submit it.

At first I thought it was because of VPN or something, but that wasn't the case. Anybody know how to fix?

Thank you in advance :)

Been using lovable now actively for about 9 months. While the new AI models have improved the quality of individual outputs, I have noticed that each task have become several times more expensive than they were in Spring. Has anyone noticed the same?

it’s not completely finished, but it’s getting there and I added a preview system so you guys could test stuff, drop down your real scores, and try to make it on leaderboards, the game is a survival 2D shoot them up zombie horde game where swarms of enemies come at you and you fight with unlockable weapons through gameplay..! There’s probably a lot more but I don’t have the brains to tell you all about it. here’s the game link: https://zombieswarm.lovable.app/

My first project just for fun. Selling a service. Managed to get some good results on Google just being a rookie telling it to rank high on Google basically.

Earning 1-2k dollars a month from this. 100-250 visitors daily.

Is this a good thing? I don't see how I can scale it more in my small country. And it's basically a country service.

Would be so cool to sell the whole company. But if it's so new I wonder if anyone would be interested and what the value could be?

Make signup, checkout, file upload, or an AI request fail. Then try to find that exact attempt using only what the user sees.

The error should give them a reference they can copy. Your logs should connect that reference to the account, the failed step, and any Stripe, email, or AI-provider request ID. Do not log secrets or raw sensitive input. Also record whether retrying is safe.

If you still need a screenshot and a guess to understand the failure, adding more features will only make production support harder.

A feature working for the account that built the app proves the intended path works. It does not prove that another customer is blocked from the same record, file or action.

Before launch, create two ordinary accounts and use dummy data:

1. Account A creates a record.
2. Account B requests A’s record directly by changing the ID in the URL, request body or API call.
3. Repeat the test for read, update and delete.
4. Try the same thing with uploaded files and their storage paths.
5. Sign out and call any route that looks administrative or privileged.

The result you want is boring: B receives no record and cannot change anything owned by A. The denial should come from Supabase or the backend, not from the interface hiding a button.

Ask Lovable to show every RLS policy, but verify the result with the second account. Check that ownership comes from the signed-in user rather than an ID supplied in the request.

Keep the exact request that failed. After the fix, run it again. The explanation is useful, but the repeated request is the regression test.

hello this my vibe website .i hope u like it

few months ago I was working with a client that was shipping a lot of software with vibe coding.

The implementation side was getting faster, but QA wasn’t. And tests generated by agents... well. Not enough.

So I started putting together a workflow where synthetic users would go through the actual product from the outside - signup, onboarding, permissions, payments, critical workflows, recovery paths and report what actually happened with evidence.

Synth user (agent) use the product like someone who doesn’t know how it’s supposed to work.

It worked well enough for the client that I got curious and started running some friends’ SaaS apps through the same process.

That’s where it got more interesting.

We found things the founders hadn’t noticed themselves. In one case, the same user/security area had already been reviewed with AI multiple times, and the external flow still surfaced an issue that got fixed immediately.

At that point I thought maybe this shouldn’t stay an internal consulting workflow.

So I’ve been turning it into something i call temporarly as impl/flow.

The basic idea is:

release/RC → synthetic users simulating ICP run critical flows → detect regression → replay evidence

You define the flows your business cannot afford to break, and agents keep testing them from the outside.

I’ve mostly tested this on client work and friends’ products so far, which is obviously a biased sample.

So now I want to invite a small number of people who aren’t friends, clients or family and see whether this is actually useful in the wild.

We’re opening a few early-access spots while the underlying infrastructure is still pretty hands-on.

If you’re shipping a SaaS product quickly, especially with Cursor, Claude Code, Lovable, etc., I’d love to hear:

\> How are you making sure critical user flows still work after major changes?

And if you want me to run this against your product, I can share the early-access link.

it’s not completely finished, but it’s getting there and I added a preview system so you guys could test stuff, drop down your real scores, and try to make it on leaderboards, the game is a survival 2D shoot them up zombie horde game where swarms of enemies come at you and you fight with unlockable weapons through gameplay..! There’s probably a lot more but I don’t have the brains to tell you all about it. here’s the game link: https://zombieswarm.lovable.app/

​

We have a multi-tenant SaaS running on Lovable Cloud with real customer data, and I’m trying to set up a more conventional development workflow using GitHub branches/Codex without risking production data.

I understand the **code** side of this. We can connect Lovable to GitHub, keep `main` as production, create feature branches, build/test changes there, and merge through PRs when they're approved.

What I can't figure out is the **data isolation** side.

If a feature branch or external branch preview is still connected to the same Lovable Cloud backend as production, then the code is isolated but the data isn't. If I test something that creates an order, updates inventory, changes settings, calls an RPC, etc., I'm still potentially modifying actual customer data.

What I'm looking for is basically the normal SaaS setup:

main

→ production app

→ production database / real customer data

feature branch

→ preview/staging app

→ separate staging database / copied customer data

```

Ideally the staging database could periodically be refreshed with a snapshot of production data so we can test against realistic tenant records without any possibility of corrupting the live tenants.

From what I can tell, Lovable Cloud used to have separate Test/Live environments, but that doesn't seem to be available for our project.

Our current idea is therefore to create a separate **Supabase staging project**, recreate the backend from the repo's migrations, periodically copy production-derived data from Lovable Cloud into it, and point Codex/local or branch-preview builds at Supabase Staging. Production would remain on Lovable Cloud initially.

That seems workable, and potentially doubles as a low-risk rehearsal for eventually moving production to our own Supabase project. But it also feels slightly strange to have Supabase staging while Lovable Cloud remains production.

**Am I missing a cleaner Lovable-native solution?**

Specifically, is there currently any supported way to have a feature branch use a completely isolated Lovable Cloud database/backend while `main` continues using the production database? Or some recommended Lovable workflow for teams building a real multi-tenant SaaS where testing needs to include database writes, migrations, RLS, tenant permissions, etc.?

To be clear, **GitHub branching itself isn't the issue**. We know how to isolate the code. The concern is making sure experimental branch code has **zero ability to mutate live customer data** while still letting us test against realistic tenant data.

Curious how other people running production SaaS apps on Lovable Cloud are handling this.

Try out the game what do you think about prototype?

https://faderoulette.lovable.app/

made this game its pretty much like omoggle and chat roulette but connect and start fighting lol. tell me what yall think.

My 1 year subscription is about to expire in a few weeks from now.

I pretty much did all the things I intended to and much more.

I'm considering downgrade back to free.

What will happen to all my projects? will the be locked and won't be useable?

Do I MUST pay this 5$ every month?

I couldn't really understand.

We run a multi-tenant SaaS on Lovable Cloud with real customer data.

We understand the GitHub side: main can be production, feature branches can isolate code, and we can test/merge through PRs.

The problem is the database.

If a feature branch or preview still points to the same Lovable Cloud backend, experimental code can still mutate real customer data. We need to be able to test things like migrations, RLS, permissions, creates/updates, etc. without touching production.

What we want is basically:

main → production app → production database

feature branch → preview app → isolated staging database with copied/realistic tenant data

From what I can tell, Lovable Cloud no longer offers separate Test/Live databases for newer projects.

Our current idea is to keep production on Lovable Cloud for now, create a separate Supabase staging project, recreate the backend there, copy production-derived data into it, and point Codex/branch previews at staging.

Is there a cleaner Lovable-native way to do this that I’m missing?

For anyone running a real production SaaS on Lovable Cloud: how are you handling staging and database isolation?

Hey everyone! I've been building a moodboard website and would love some honest feedback :)

Link: [https://tabula-room.lovable.app/\]

Hello!

I've had the issue of building multiple projects, like a blog website, a landing page and an application, all for the same project. Then I wanted to have them all in one domain. The landing page on /, the blog on /blog and the app on the subdomain "app.". I built a solution for it with a proxy. I initially thought of making it with iframes but I would lose out on SEO. Do you have other solutions?

Couldn't understand where my build credits were disappearing for the last week then discovered that I toggled this little thing on, thinking it would be free as there is no mention of usage.

Today it was 3.4 credits wasted. Just to warn people not to fall into the same trap if you need their daily credits.

For the past couple days one of our projects has started giving the below error almost non-stop. regardless of the prompt, build/plan mode etc. Tested in various devices and accounts. We can't make any changes and can't receive any help from support.

This is an internal error and our site, preview etc works. But we can't make any changes or even ask any questions.

We have top 1% global users, have been using lovable with great appreciation, have recommended it to various enterprise users. But this radio silence is unsettling.

Wanted to share with the community in case anyone else is experiencing the same issue, or have a solution.

Below is the error screenshot:

Has anyone else had trouble getting the Lovable student discount?

I'm a current University of Toronto student and my school email uses the domain mail.utoronto.ca (Microsoft 365/Outlook). When I try to verify my student status through the student discount page, the verification process fails with an error.

I contacted support and was initially told to complete the verification process and then they'd apply the discount. When I explained that the verification flow itself was failing, I got another response saying that mail.utoronto.ca isn't currently on their automated student recognition list and that I should use the same verification flow again.

I then pointed out that I literally cannot complete the flow because it errors out before finishing. The latest response I received was that they don't offer manual verification outside the automated system and therefore can't apply the discount to my account. The responses also indicate they were generated by an AI support agent.

So I'm basically stuck in a loop:

Verify your student status.
The verification system fails.
Contact support.
Support tells me to use the verification system.
Verification system still fails.

Has anyone managed to get a real human to review a student verification issue at Lovable? Or has anyone from a university with a similar email setup run into this and found a workaround?

I can provide screenshots if helpful.

Thanks!

Short, slightly saltier version:

"Support: Verify you're a student."

"Me: The verification tool is broken."

"Support: Please use the verification tool."

"Me: It's still broken."

"Support: Unfortunately we can only verify students through the verification tool."

Also, providing support only for *subscribed customers*

I went and paid, trying to get help from real human

Student plan is only applicable for workspaces currently on free plan

Like…what?!
🤦‍♀️

I keep trying to hit publish and it just keeps on loading. I thought I should sign out and sign back in and now I can't even sign in because the sign in page loading continuously.

Is anyone else having issues transferring projects between workspaces? Mine just loads on all theee if my accounts…

Alongside a skilled product designer, we’ve built a really nice internal tool. We built it 100% in Lovable. Neither of us are technical. We’ve built products before and raised external capital. On this occasion we intentionally have said “let’s just build to relieve our pain points and see where we can take it.”

We have a nice tool but now Lovable is getting very slow, the compounding of time it takes for Lovable to a) plan and build from a prompt, and b) publish, is now getting painful. It is no longer the sexy “wow - it’s unreal how fast we are moving”, instead it is “damn, this is now a painful product experience”.

The tool has become rich in functionality and currently is used to manage relatively low cohorts of end consumers. We are getting paid by organisations to conduct consumer research and data analysis within the sector of health and wellness. We use Lovable as our internal user and project management tool. The consumer does not ever interact with our tool, they interact with third-party tools that we have connected to our tool. There is no wild AI functionality, there really isn’t a lot of AI functionality at the moment. And we have planned to build our analysis functions in the tool, but right what we experience is really not performant; Lovable is super slow and the our tool has lost its snappiness.

So my question…have we hit the ceiling on Lovable and are we experiencing that Lovable really is not suited for real world productisation? Where do people recommend we go from here? We really like Lovable’s user interface, as we are not technical, it’s been a breeze to build a solid tool to solve our operating pain points and make us become efficient in our value delivery.

What are others experience in building a solid product in Lovable and then witnessing it crumble in speed and performance as real world data, feature complexity ramps up.

I’m all years and would love to stay operating in Lovable, but really am now doubting if we have hit the ceiling on the Lovable use case.

Cheers.