From Vibe-Coded Prototype to Production: Who Maintains AI-Built Internal Tools?

At Lanch, a prototype is deliberately fast.

As Leandro describes it, the prototype is one or two days — just enough to test the functionality with the user and make sure it has some fit in what it's doing.

The trap is over-investing before validation.

Leandro warns that with tools like Replit and Lovable, you can get lost in over-optimizing the whole time, and then you're building an MVP or a prototype for two weeks .

The discipline is to keep the first build short and prove value before going deeper.

The distinction at Lanch is sequential.

The prototype is the one-or-two-day build used to test functionality with the user and confirm there's fit in what it's doing.

As soon as that's validated, the team asks whether it can be built from a technical perspective and what's required to integrate it with existing systems.

If it needs to integrate with other systems, that adds constraints; if it doesn't, that gives more freedom.

Only then is the MVP developed , and that MVP gets handed over to the tech team.

In short: the prototype proves the idea works; the MVP is the validated, integration-aware version that engineering takes forward.

The path at Lanch runs through the tech team.

Functions come up with their own MVPs and build them with Lovable or Replit.

Once a tool starts delivering value, they write PRDs with the help of Claude, and those PRDs are sent to the tech team — who then build those tools from the ground up again in a more robust and secure way .

Leandro's own production stack reflects that hardening step: Claude Code, GitHub, Vercel and Supabase , and sometimes Claude for design depending on the project.

Replit and Lovable are where he started because they provide structure — a direct integration to Supabase and a clear view of how apps should be structured.

Once you grasp the six or seven repetitive components in each application, you can let go and start working with Claude Code.

Lanch has been testing directly integrating Git repositories with Lovable or Replit.

The key, per Leandro, is that if you control the way you do pulls, pushes and commits in the correct way, you can really do easy contributions — especially for small features — from someone who's really close to the product and the use case .

Safety comes from developer-built guardrails.

The team uses hardening jobs and skills specifically created for the front-end AI tool to manage and integrate the code.

As Vladimir summarized it, the skill gets drafted by a developer to make sure that everything fits correctly and has full context about how the main repo works, to ensure things don't break.

The mechanics: create a new Next.js folder locally, use the skills developed by the tech team so it has the right scaffolding, then import that repo into Lovable so a non-technical person can build on top of the custom-built scaffolding.

You have to pre-check what requirements the front-end building app has, to make sure the codebase you're importing is compatible with it.

Ownership ultimately sits with the tech team, who rebuild validated MVPs from the ground up in a more robust and secure way.

But Leandro flags a real maintenance gap in how these tools get run day to day.

Front-end building systems help by maintaining an overview of all aspects of the development process — in Lovable you can see your current cloud costs, how much data you're storing, and how much you're spending across API integrations.

That visibility disappears in raw Claude Code: you basically need to set up this system and overview yourself , and you can completely lose the overview of which secret you have stored where .

Security, he notes, is a recurring concern.