From a Vibe-Coded Travel App to a Real Product
How we took a fully working Lovable-built business app — 2,000 commits, lots of technical debt — and migrated it into a production-grade system in three weeks.
We recently worked with a business owner in the travel industry who had done something genuinely impressive: built a fully working business app in Lovable without writing a single line of code.
The prototype was already doing real work. A mini CRM. AI-based ticket parsing. Booking management. Automated email reminders. Integrations with ticket purchasing systems. All created by a non-technical founder with a clear vision of how travel agents should operate.
And it worked – until it started to hit the limits of prototype logic.
After roughly 2,000 commits, the cracks became harder to ignore: data inconsistencies, regressions, and the kind of instability that shows up when an app grows faster than the architecture underneath it.
The goal was no longer just to make it useful for one person. It had to become production-ready and stable enough to support other travel agents as well.
What we found under the hood
The app was built on Lovable's standard stack: Supabase, React, TypeScript, Tailwind, and Shadcn, with communication handled through the Supabase client, row-level security policies, and a set of Supabase Edge Functions for heavier logic.
The real challenge was not the stack itself. It was everything that had built up around it: migrations that could not be executed reliably, no straightforward way to create a proper database dump, and a growing layer of redundant logic spread across dozens of tables. Like many no-code and vibe-coded systems, Lovable offered speed early on – but not much transparency once the system became more complex.
What we did
We kept the frontend intact and introduced a proper API layer with Fastify between React and Supabase.
That changed the architecture from:
React → Supabase
to:
React → Fastify API → Supabase
This gave us much more control over the system and allowed us to move beyond some of Supabase's practical limitations, including execution time caps and increasingly fragile stored procedures used for more complex logic.
We deployed the new setup through GitHub Actions and Railway, and completed the migration – including the production environment – in about three weeks, with one developer supported by a QA specialist.
AI wrote most of the migration code
One of the most interesting parts of this project was how far we pushed AI in the actual delivery process.
Most of the migration code – including scripts – was generated with LLM support, mainly Claude Opus 4.5 and 4.6. In many cases, the output required only light adjustments. The developer's role was not to manually write everything from scratch, but to steer the system well: make the harder architectural decisions, guide the model toward better implementation patterns, and review the output.
We also built a workflow around this that we sometimes describe internally as our own version of Lovable: a Vibe Kanban setup based on Claude Code, Codex, GitHub Actions, and isolated branch environments on Supabase and Railway.
That means new tasks can now be developed in separate environments, previewed safely, reviewed, and only then merged. The long-term goal is simple: preserve the speed of AI-assisted product development, but put it on top of real engineering foundations.
What comes next
The migration phase is now complete. The next question is the one that matters most: whether this setup will scale cleanly for both the current user and future users.
That is the real test. Two lessons already stand out.
First, once someone has experienced the speed of AI-native building tools, they will expect that pace to continue. That expectation has to be managed carefully – especially when the initial speed came with significant technical debt.
Second, the earlier this kind of migration happens, the better. At around 2,000 commits, this was already a large app with even larger debt underneath it. Making the transition sooner would have made parts of the process much simpler.
Still, we would absolutely do it again.
There is real potential in taking vibe-coded prototypes and turning them into production-grade systems – as long as someone is willing to bring architecture, discipline, and a proper delivery layer underneath them.