Path to Production.
The most common real case

A Lovable app just landed on IT's desk.

Someone on the business side built a working web app in Lovable, it looked great in the demo, and now it's been handed to IT to "make it real." This is exactly how I take it from that handoff to something the firm can safely run, and how the path changes depending on what the app turns out to be.

The running example

A research analyst built a page in Lovable where you drop in a folder of company financials and ask questions about them. It works. The deal team loves it. It's now IT's problem. Let's walk it through.

The decision at a glance

One app in, one clear path out.

Every handoff runs the same route. Two questions decide how far it goes, so effort always lands where the risk actually is. The rest of this page is just each box, explained.

No Yes No Yes Yes Either way A Lovable app is handed to IT Look under the hood — what data, who uses it, blast radius Does it even need to be an app? Retire → shared tool or prompt. IT never supports it. Sensitive data, or many users? Keep it light → lightweight app, hosted, monitored Harden fully contain data · sign-on + entitlements ground the answers · make it observable Will others want the same thing? Templatize → reusable starter for the next apps Assign owner · supporter · sign-off · failure plan, then hand off Secure · Owned · Supported
Step 0 · look under the hood

What a handed-over Lovable app usually looks like inside.

None of this is a knock on the builder. Lovable is built for speed, not for a confidential firm's production bar. These are simply the gaps I expect to find, and knowing to look for them is half the job.

The AI key is in the page itself. Anyone who opens the browser tools can copy it and run up your bill.
No sign-on. It's a shared link, so anyone with the URL can use it, inside or outside the firm.
Data leaves the firm. Those financials are being sent to a public AI, outside any boundary you control.
Everyone sees everything. No sense of who is allowed to see which company's numbers.
Answers aren't grounded. It will confidently make up a number with nothing to check it against.
It runs on a personal account. One person's login, no logging, no owner, nothing IT can support.
A

Evaluate it, in a fixed order

Assume it works in the demo and is unsafe in production until proven otherwise.
1Blast radius
Who actually uses this, and what data does it touch? A personal helper and a tool over confidential financials are completely different risks, and this one question sets everything that follows.
Sets the tier
2Data & secrets
Is confidential data leaving the firm? Is a key sitting in the page? These are the two that turn a demo into an incident, so they get checked first.
Highest severity
3Access
Is there any real sign-on, and should everyone really see everything? In a confidential firm, "shared link" is not an access model.
Entitlement
4Correctness
Does it actually do what it claims, and does it fail safely? An AI tool that invents numbers is worse than no tool in an investment context.
Trust
5Operability & support
Can you tell when it breaks, and could anyone but the builder keep it running? If not, it isn't ready to be relied on.
Supportable
The evaluation produces a decision, not just a list. Promote it, rebuild the risky parts, or honestly retire it and turn it back into a shared tool if it never needed to be an app. That decision picks the path below.
B

Make it production-ready, in priority order

Secure the data first. Cosmetics last. Fix the thing that would hurt most, first.
1Move the AI call server-side
The key comes out of the page and into a vault. Nothing sensitive lives in the browser anymore.
Contain
2Keep data inside the firm
Point it at the firm's own approved AI instead of a public one, so confidential financials never leave a boundary you control.
Contain
3Add sign-on and limit access
Real sign-on tied to the firm's identity, and access enforced beneath the app so people only ever see the companies they're entitled to. Never rely on asking the AI to keep a secret.
Lock
4Ground the answers
Every answer cites its source so it can be checked, with guardrails against manipulation. No more confident invented numbers.
Trust
5Make it observable & repeatable
Logging and error handling that fails safe, separate test and live environments, and one-click deploys with easy rollback, off the personal account for good.
Operate
6Hand it off
A named owner, a short runbook, and support that isn't one person's memory. Now it's genuinely IT's to run, not IT's to worry about.
Own
The variants

Four ways this actually goes.

Not every Lovable handoff becomes a production app, and that's the point. The evaluation decides which path it takes, so effort lands where the risk is.

Variant 1 · Retire
It turns out three people use it once a month. It never needed to be an app. Turn it into a shared tool or a saved prompt, log it in the catalog, and free IT from ever supporting it.
Best outcome, often
Variant 2 · Keep it light
Useful to a team, but only touches public or low-risk information. Host it properly with basic sign-on and monitoring. Don't gold-plate it. A lightweight app is the right size.
Right-sized
Variant 3 · Full production
It touches confidential financials and the deal team depends on it, our running example. It earns the whole path: containment, sign-on, entitlements, grounding, monitoring, ownership, handoff.
Earns the controls
Variant 4 · Productionize & templatize
It's genuinely great and others will want the same thing. Ship it fully, then turn the safe foundation into a starter template so the next five Lovable apps begin production-ready instead of starting over.
Compounding win
The through-line
The builder keeps the credit. IT keeps the control.

People rally when you frame it as getting their idea safely to the finish line, not as tearing their work apart. That is how citizen building becomes an asset instead of a liability.

← Back
Match the size