From Lovable to production in 2 weeks

The client came to us with something impressive and something incomplete, sitting side by side: a working PropTech SaaS prototype, built entirely in Lovable on top of React and Supabase, that looked convincing in the preview. What they didn't have was anything that resembled production.

No CI/CD — every change required a manual deployment. No monitoring — no way to see whether the app was healthy, and no alert if it wasn't. File storage was sitting in Supabase Storage, which was fine for prototype scale but about to hit cost and performance limits the moment real users arrived. No one had looked at the code for security issues. And the launch was coming up.

The question wasn't whether to rebuild. The prototype was fine. The question was how fast we could put production-grade infrastructure underneath it, so the client could actually let users in.

The challenge

• Working prototype, no production path. The app ran in Lovable's preview. There was no plan for how it would run anywhere else.
• Manual deploys only. Every change required someone with the right access to push it out by hand — the founder-as-infra pattern described in our article on hidden costs.
• Zero monitoring or alerting. If the app broke, no one would know until a user complained.
• File storage on Supabase Storage only. Fine at prototype scale; expensive and brittle at real-user scale.
• No security review. None had been done. The plan was to launch; the risk was unknown.

What we did

Two to three weeks from first call to production handoff. We ran three tracks in parallel: the security pass, the infrastructure build, and the storage migration.

1. OWASP Top 10 security audit. A structured pass against the OWASP Top 10. Critical issues identified, prioritized by business risk, and fixed. (Specific findings are not published — they could re-identify the client.)
2. CI/CD pipeline. Automated tests and deployment on every push. No more manual deploys; no more single-person bottleneck.
3. Production server configuration. Proper environment separation — staging and production as distinct environments, each with its own config. No more "the app is wherever the founder's browser happened to be."
4. Monitoring and alerting. 24/7 error and performance monitoring, with alerts routed to the right place. Failures become known in minutes, not days.
5. AWS S3 + CloudFront migration. File storage moved off Supabase Storage onto S3 with a CloudFront CDN. Cheaper, faster, and the storage ceiling goes away.
6. Domain, SSL, and infrastructure configuration. Proper HTTPS, DNS, environment variables, and production build pipeline — the unglamorous work that separates a deployed app from a demo.
7. Handoff documentation. Written docs for the client's team: how to deploy, how to rotate credentials, how data flows, what's brittle and why. The documentation is the part that makes the next engineer they hire effective on day one instead of day thirty.

Results

At the end of the engagement, the application was genuinely production-ready — not "marketing-department production-ready," but the kind that holds up when real users arrive. What changed concretely:

The founder no longer had to be present for a deploy to happen. The team had alerts in place before they needed them. The storage plan stopped being a cost surprise waiting to happen.

What we'd tell another founder in the same situation

Case studies are most useful when they generalize. If you're looking at a Lovable, Bolt, or v0 prototype that's about to meet real users, the shape of the problem is usually the same. A short checklist, distilled from this engagement:

• Do the security pass before launch, not during. OWASP Top 10 is a starting point, not a ceiling — but starting there catches most of what actually gets exploited against young SaaS products.
• Treat manual deploys as a founder tax. If you're the only person who can ship, you're not just the engineer — you're the deploy system. CI/CD is a one-week investment that buys that time back forever.
• Turn on monitoring on day zero, not day of-first-outage. It's always a three-hour task to set up before you need it. It's a multi-day task to set up while something is on fire.
• Assume you will outgrow managed-service storage. Supabase Storage, Firebase Storage, Vercel Blob — all fine to start with, all with a ceiling. Plan the migration path before you need it; it's ten times cheaper than the panic version.
• Document the handoff surface even if "handoff" is future-you. The person who will struggle without deploy docs is usually a version of yourself from three months ago.

For the longer version of these patterns, see our articles on invisible bugs in AI-generated code and when to hand off your MVP.