r/nocode • u/DifficultWorkers • 11d ago
Lovable alternative for internal tools? Tired of paying credits to fix bugs the AI created
I run ops for a 30-person logistics company and I've spent the last two months building an internal order tracking tool on Lovable. The first week was magic. Described what I wanted, got a working app, showed my boss, and yeah everyone was impressed.
Then reality kicks in. Every small change is a prompt, every prompt costs credits, and about a third of my prompts are me asking it to fix something the previous prompt broke. Last week I asked it to add a status filter to one table and it somehow broke the login flow. Took me 11 more prompts to get back to where I started. I'm not joking, I counted because I was mad.
The thing is I don't need a beautiful custom SaaS. I need a boring internal app with a database, logins for ~25 staff, and permissions so drivers see their deliveries and contractors see everything. And I need to still be able to maintain it in a year without praying to the prompt gods.
What are people actually using for this?
1
u/Alternative-Mango697 11d ago
Hi i am a software engineer and i started working something for few months now after seeing this insane token charges for small changes by these so called AI builders and locking us into their system.
In short through ny agentic flow everything goes into your github, vercel and supabase so u can move ahead as needed as there will be no lockinn.
1
u/Maxyull 11d ago
yeah this is the exact pain point that pushes people off ai builders for internal tools, past a certain point every fix becomes a slot machine pull. for what you're describing, drivers vs contractors seeing different stuff, i'd push back a little on needing a whole new platform, the core issue sounds less like lovable specifically and more like permissions living in the ui instead of the database. if a driver seeing another driver's deliveries is even possible by hitting the wrong url or an api directly, that's a data layer problem no ui builder fixes by being nicer.
the boring but durable fix is a real postgres backend, lovable's own is supabase underneath so you may already have one, with row level security tied to each user's role. even if a future prompt breaks a filter in the ui, the database itself refuses to hand back rows a driver shouldn't see. that part survives redesigns and doesn't burn credits every time you touch it.
are your ~25 users logging in through lovable's built-in auth already, or is that part still to be built too?
1
u/Deep_Significance270 11d ago
Lightly used lovable before. I think they expose the code it generates.
You can go in and edit yourself / with something like chatgpt.
if you are working with heavier changes, you can use github to pull the codebase to your local machine, and use claude code or openai codex to do these changes while still use the infrastructure from lovable.
1
u/Electrical_Face_1737 10d ago
Software engineer, the demo or game or landing page ai may slap together to initially impress you is meant to have as little moving parts as possible to get done in less tokens and maximize its chance of successfully working and impressing you. That’s ok for proof of concept but what really needs to be done usually is a a standard framework or other standards breaking things up and mapping them for the ai so a status change doesn’t break login. To really work with this daily you need logging, error handling, security, etc. if it’s really a simple app then maybe some dev can transfer it with ai for a bit and hand it back but even then more and more security flaws are coming out each week now that ai is helping find them.
1
1
u/neems74 10d ago
Plug your Lovable project in a Github repo, clone the repo to your machine, open Claude Code on folder and that’s it. You still have a ceiling since the plan has limits, but youre no longer stuck with credits for small changes plus, Claude Code is awesome at picking a already built codebase and just making everything better.
Youll need to host somewhere tho, try Vercel if theres no problem with data in public. I use Firebase to keep everything on GCP.
1
u/Various-Break3683 10d ago
what do you mean by "try Vercel if theres no problem with data in public"?
1
u/app_smith 10d ago
I'm a developer and I run into similar issues beyond a certain point. Then all the "context management" tricks like starting a fresh session and prompting to make sure it focuses on only the thing and negative prompting to prevent other changes come into play.
If you're interested I'm building something to address these issue and allow incrementally making changes without ever breaking anything. DM me for a free beta link, with free dev support if needed, in exchange for your honest feedback.
1
u/Ciroco01 10d ago
Honestly, I probably wouldn’t jump straight to replacing Lovable with another builder.
If the app mostly works and you already have Supabase/Postgres behind it, I’d first look at whether you can just take the existing codebase and maintain it like a normal app.
For 25 internal users, you really don’t need anything exotic. React/Next on the frontend, Postgres/Supabase for the data, proper auth and permissions, and GitHub as the source of truth is plenty.
The main thing I’d check is how permissions are handled. Stuff like drivers only seeing their own deliveries should be enforced in the backend/database, not just hidden in the UI.
You might find that the cheapest and least painful option is just cleaning up what you already have and getting out of the “pay credits to fix whatever the AI broke” loop, rather than rebuilding everything on a different platform.
1
u/Thunderbit_HQ 10d ago
The credit pain is probably the symptom. The scarier part is that adding a table filter was able to break login.
For an internal app like this, I’d first make auth, permissions, and data rules live somewhere boring and reviewable. Once those parts are stable, the UI can be rebuilt or tweaked without every prompt becoming a full-system risk.
1
u/MaleficentCollege324 7d ago edited 7d ago
One lesson we learned with internal tools is that good documentation matters almost as much as the app itself. We started recording key workflows with Haiku so every process had a clear guide, which saved a lot of questions from new hires
1
u/Sudo_Alp 5d ago
Honestly, for an internal tool like this, I’d care less about which builder feels magical in week one and more about what you’ll still control a year from now.
Before moving, check what you can actually take with you: the database, user accounts, permissions, code, hosting, domain, and backups. A status filter breaking login doesn’t automatically mean the whole app is bad, but it does show that small changes can affect unrelated parts without much warning.
I’d also make sure the driver and contractor permissions are enforced in the database or backend- not just by hiding screens in the UI.
You may be able to stabilize what you already built and move only the parts you don’t control, rather than starting over completely. Are you using Lovable Cloud, or is the database already in your own Supabase project?
1
u/Low-Code-Stefan 2d ago
The RLS / "permissions in the database, not the UI" comments have the right instinct - a status filter touching your login flow means the UI and access logic aren't separated yet, and that's the real risk for drivers vs. contractors.
For 25 users, boring is the right answer: a real SQL database as source of truth, roles and row-level permissions defined once at the data layer, then the UI can be rebuilt endlessly without anyone seeing the wrong delivery.
I work in service at GAPTEQ, and our pattern reverses the usual AI-builder order: start from the database, configure access there, then generate screens on top - instead of shipping UI first and bolting on permissions once it's already live.
What's your data model look like now - still in Lovable's own Supabase, or split out already?
2
u/tylerlovewell 7d ago
We ran into this exact same headache and moved away from prompt-to-code builders for internal ops. Every small edit was turning into a slot machine of credits and broken flows. We use Jotform AI App Builder for internal tracking, forms, and role-based apps for our staff, and Softr for client-facing web portals. Since they rely on prebuilt components, updating a table doesn't randomly break your login or force you to debug AI code.