How to Love Lovable

Lovable, and the other similar wonderful apps, are genuinely impressive. Our operation and product people wanted nothing but to build things, taste the cursed joy of software engineering. They have ideas, they understand their problems, and they’re tired of waiting for priorities. so building they did..

Which is great, until it isn’t.

The Problem: When Fast Becomes Fragile

Our team, eager and smart, immediately connected their Lovable apps to our API and started building tools: onboarding status dashboards, master data interfaces and other back-office functionalities that would save time and help our customers immediately. They’ve worked in our development environments, built a working app, and then they wanted to go to production.

That’s when we hit the walls. Multiple, actually:

First: API and Domains. Our backend is granular by design, built for an agent-focused architecture with detailed endpoints with proper separation of concerns through well-defined domains. But asking a product person to chain together multiple API calls to display a customer’s onboarding? That’s not reasonable. They just wanted a button that says “show onboarding status.”

Second: Access control. Our API does necessary role-based access management, but since it’s not built for a frontend (we have a lovely BFF for that), it wasn’t equipped to handle direct connections from these Lovable apps. Since we do not track the users, it is very hard to bake in the rbac structure into these apps.

Third: Environments, Versions and Deployments. While Lovable-like tools allow us to publish, they do not differentiate between environments. We tried to overcome this by naively allowing a selector in the app but, the apps never able to keep up with the changes on the API level. Publishing a dev version, broke production.

Also, the apps, further developed, were hard to keep track. The version this button used to work is a very hard time to go back. No stable releases, no rollback strategy, no way to say “this version is in production, that one is still being tested.” Just a continuous stream of changes.

That’s where we needed a production-grade infrastructure/process around Lovable’s speed, to get the best of both worlds.

The Insight: Lovable Already Solved This

Here’s what made everything click: Lovable itself is a wrapper app.

Think about how their editor works. The left side is the Lovable IDE (the parent). The right side is the app running in an iframe (the child). The parent controls code changes, building, and deployments. The child just focuses on doing one thing well. We reckoned we could use the same pattern.

The Solution: Jantro

So, like any other busy startup team who wants to slow down to speed up, we built our own solution: Jantro, a Firebase-hosted parent app that wraps all our Lovable child apps. Here’s the architecture:

┌│││││││││││└┌│││││││└─────────P┌││││││││└──B••••••──a────a──r────cASRSAE──e─S•••───kuiotcn──n─i───etmuocv──t─dAAL───nhptrei───eupo───dleesr──A─btpg──│├│↓─vissso──p─ahso────fafn──p─ru────olittcm───t───rieohoe──(───RF─ddenn──F───oi─Laitt──i┐││││││││┘─ur─otrnAr-──r─te─viotPoa──e─eb─aoueIlw──b┌││││││││└─sa─bntra──a───s─lenkpr──s───ae─eaeee──e───l─alyr───C(RApp──lF─(gsc──H─hLePao──u─Bgaao──o─ioqIrs──An─Frnapn──s─lvuet──Pc─Lednpf──t─daeUnM──It─)gdi──i─bsRte──i─a3g──n─AltLs──co─trs──g─pesvs──an─ide──)─p,fia──ls─oc───trag──l─npr───iooe──s─sae───fkm───rt───re──t─ts───an──h─y───m──r────e&──o─a───)──u─p─────g─p─────h─s──┐││││││││┘───────────────────────────┐│││││││││││┘──┐│││││││┘

How It Actually Works

Parent app sits in separate repo, and runs in Firebase. It authenticates users via Google OAuth, validates their email domain (@integral.de or @ext.integral.de), and fetches the list of apps they’re allowed to see from Firestore. When a user selects an app, it loads in an iframe. A CrossAppCommunicator class handles secure postMessage communication between parent and child.

Child apps check on mount if they’re running in an iframe. If yes, they send a getToken and getApiBaseUrl message to the parent. The parent responds with the credentials, which the child stores in localStorage. The child then renders, using those credentials for all API calls.

BFL (Backend for Lovable) is a Firebase Functions Express app. It verifies the Google ID token on every request, checks the user’s email domain, and proxies requests to our internal microservices. During development, we also whitelist specific Lovable preview domains (using the project ID) so apps can make authenticated calls directly from the Lovable editor.

The parent controls auth and environment, the child just renders. No shared state, no complex handshakes, just messages and tokens.

Once an app is deployed to staging or prod, the team continues to work inside Lovable app (dev environment), without impacting or breaking the deployed apps, hence operations.

That functions layer is where the production hardening happens. It’s our “Backend for Lovable” (BFL):

  • Unified entry point: One API base URL instead of managing multiple endpoints. Child apps don’t need to know about our internal service topology. BFL also serves 3rd party API without exposing secrets.
  • User-based access control: Authentication and authorization happen at the user level. Only users with @integral.de or @ext.integral.de emails can access the API. App visibility in the sidebar is controlled through config-based permissions.
  • Environment propagation: The parent knows which environment it’s in. Child apps just ask for apiBaseUrl and get the right one.
  • Versioning: GitHub Actions deploy child apps to Firebase Hosting with proper tags. v1.2.3 goes to prod, v1.2.3-rc goes to staging.

What We Actually Built

Using this pattern, we shipped four production apps in six weeks:

  1. Onboarding Status Dashboard - Shows customer onboarding progress
  2. Invoice Management - Create and view invoices
  3. Master Data Interface - Manage core business entities
  4. Event Store Viewer - Debug our event-sourced system

Each one was built by non-engineers using Lovable, wrapped by Jantro, and deployed to production with proper auth, access control, and environment handling.

The Setup: Fast Scaffolding

When anyone at Integral wants to build a new app, the workflow is:

  1. Create a new Lovable project starting with an app name prefix (jantro-) so the system can distinguish between prototypes, ideation etc…
  2. Connect it to GitHub repository (or ask a dev to do it)
  3. The GitHub app periodically checks for new Lovable repos using the prefix, once found, injects the template code. (can be also manually triggered)
  4. Paste one prompt into Lovable: “Wrap this app with the jantro-authenticator template”
  5. Use the BFL layer API to build your app
  6. Tag for deployment: v0.x.y-rc for staging, v.x.y for prod

The initial setup takes 15-20 minutes, but it’s mostly waiting for GitHub Actions. Then people build.

What We Learned

This pattern works because we stopped fighting against Lovable’s nature. It’s a rapid prototyping tool, and that’s valuable. We just needed production guardrails around it.

The iframe wrapper pattern is surprisingly powerful. By controlling the parent, we control everything that matters—auth, routing, environment, access. The child apps stay simple and focused.

And most importantly: our product people are shipping real tools. They’re not writing tickets and waiting. They’re building, testing, and iterating. We review, we secure, we deploy.

That’s how you love Lovable. Not by using it for everything, but by wrapping it in just enough infrastructure to make it production-ready.

What We’d Improve Next

This works for our team size and velocity, but we’re aware of the shortcuts:

App-level API isolation: Right now, once a child app has the auth token, it can technically call any BFL endpoint. We control which apps users see, but not which APIs each app can access. For a team of 20, this is acceptable. For 200, we’d need proper app-scoped API keys.

Automated workflow distribution: We manually copy deployment workflows to new repositories. A GitHub Action that detects jantro- prefixed repos and automatically distributes the workflow would be cleaner. A simple automation could save time here.

Observability: We log everything, but we don’t have proper telemetry on which apps are hitting which endpoints, only audit trails about who called which endpoint using which app. Adding OpenTelemetry would help us understand actual usage patterns and optimize accordingly.

Rollback strategy: We auto can deploy versions with tags, but rolling back requires retagging and redeploying, which does not work always well with Lovable code. A proper release management system with one-click rollbacks would reduce risk.

The point is: we shipped fast. These improvements are about scaling, not about making it work. And for now, it works.