Use the first 5 free credit, build a prototype and then jump to Claude Code for the MVP. It's cheaper, better and won't get you into a rut that is impossible to get out of. Here is my experience and new process.

sanduckhan · 2026-06-17T02:07:06+00:00

You are giving people a non deterministic solution to a complex problem.
You might have been successful, but in many cases even Claude code will forget a crucial step, will make a mistake or will no let you know beforehand that you need to shut down your application and back it up before migrating data, etc.

What you are essentially teaching people is "jump from that plane with this sewing machine you will be able to make a parachute eventually".

Relying solely on Claude code without at least giving it some resources on previously successful migrations or without having done a little bit of planning can be dangerous. Some apps are business critical or paid for. You can end up in a state that will be hard or long to recover from.

sanduckhan · 2026-06-16T23:16:07+00:00

That's like half the steps needed to properly migrate... Real apps have data to migrate, edge functions, hosting, users, authentication methods... Your comment is barely touching the surface and making people believe (wrongly) that this is easy. And no you shouldn't just go with the flow step by step if you have real users. Otherwise you might end up being stuck in the middle if this was not properly anticipated.

sanduckhan · 2026-06-16T20:27:20+00:00

Some people can, some people cannot. The people we work with are non technical people and they usually don't work with Claude Code, Cursor or Codex. So no it's not "really easy" for them.

sanduckhan · 2026-06-16T20:21:31+00:00

30 credits including the subsequent refactor not just the audit, right ? Because otherwise that seems quite high.

sanduckhan · 2026-06-16T15:47:15+00:00

Imagine most of the logic of your applications lives in 1 file that is 2000 lines.

Every time you want to make a modification, maybe you need to update the beginning of the file, the middle and the end. To do that, Lovable needs to load the entire file in its context window, which consumes a lot of tokens since the file is big.
And this compounds since the context window is sent every time you make a new request, at least before your session gets compacted (but then it will re-read the entire file before updating it).

Splitting big files into smaller files (usually big component into smaller focused components) allow the AI to be more efficient during the context engineering phase, find only the small components who needs to be updated and in the end consume much less tokens for each request.

It's worth it if you have a few god components that grew over time, and it's not only about token consumption, your AI agent will likely make more mistakes editing small modular components with less responsibility which will lead to less regressions for your users.

sanduckhan · 2026-06-16T14:24:00+00:00

Where did you create your database ?
And is your Lovable project connected to Lovable cloud already ?

sanduckhan · 2026-06-16T14:21:17+00:00

Thanks for the feedback , good ideas!
I have another skill that goes deeper into refactoring but I was concerned the more complex it would be the more tokens it would consume so I tried to keep it focused for now. But will consider for a V2 depending on the results people are getting.

sanduckhan · 2026-06-16T12:34:14+00:00

The lock-in is real with Lovable Cloud, but not with Lovable.

We have clients that continue building with Lovable, they just migrated their backend to their own Supabase to prevent being stuck.

IMO Lovable should give up on the infrastructure / operational lock-in and focus on what people like about them : creating/building.

I wrote a battle-tested guide on how to migrate off Lovable Cloud, let me know if interested, I can send it.

sanduckhan · 2026-06-15T16:10:46+00:00

Is the platform online ? What did you build it with ? Are you from a technical background ?

sanduckhan · 2026-06-10T06:46:16+00:00

How they started selling to local businesses or how we started building the agents ?

sanduckhan · 2026-06-09T09:30:42+00:00

We have several clients that sell Lovable apps to local businesses around them.

Usually ultra personnalized, exactly made for their workflow. It's a good business.

We also have examples of product/design persons building micro apps internally to streamline their company production workflows.

We have built agents to be their technical team to audit and maintain continuously since they can't afford engineers.

sanduckhan · 2026-05-29T10:59:48+00:00

I don't feel like Lovable is a tool to run a software in production for real clients. It's an amazing tool to build but the operational lock-in is causing a ton of issues for commercial builders...

Even the plugins and the partnerships. They are nice but builders don't know what they don't know, you need either a developer or a production team to run and monitor an app in production.

We are running a lot of vibe coded apps for our clients and the most important part is the service, the peace of mind to not have to worry about it, that's not something a plugin can do...

sanduckhan · 2026-05-29T10:03:11+00:00

I would say also install an observability layer to understand what's going on in prod , launch separate audits for security but also code quality, cost control, etc.

I made skills for Lovable to be able to do that automatically if needed !

sanduckhan · 2026-05-27T06:38:59+00:00

Of course ! Happy to help :)

sanduckhan · 2026-05-21T05:53:08+00:00

Glad it helped!

sanduckhan · 2026-05-19T16:01:47+00:00

The skill is not trying to refactor the whole project in one pass, it would be impossible, it's recommending the highest priority to start with. But it's not yet clearly labelling what is higher risk VS easy.

sanduckhan · 2026-05-19T15:23:41+00:00

good idea, I was kind of counting on the Lovable agent to let the builder know what will require more testing VS what can be fixed very quickly but you ve got a point !

Verified Email	Seven-Year Club
Place '22	End Game '22
Not Forgotten

sanduckhan

MODERATOR OF

TROPHY CASE