Bolt and Lovable Ship Sites. Nobody Plans the CMS.
Bolt.new and Lovable can produce a deployable site in minutes. What neither tells you is what happens when the client needs to change the homepage copy.
A client shows up with a repo. Bolt.new generated it in an afternoon, Lovable polished the design, and someone hit deploy on Vercel. The site looks good. The brief is done. Then two weeks later the client emails asking how to update the hero headline, and nobody planned for that part.
This is the situation developers are walking into with increasing regularity in 2025. Bolt and Lovable have made it genuinely fast to produce a working, deployable static site from a prompt. That’s a real capability shift. But both tools treat content editing as someone else’s problem. The output is a repo, often Astro or Next.js, with content baked into components or sitting in markdown files. There is no editing interface, no content layer, no plan for what a non-technical person is supposed to do after launch.
The Gap Is Operational, Not Architectural
The repos these tools produce are clean. The code is readable. There’s nothing fundamentally broken about the architecture. The gap is purely operational: who edits the content, and how, after the AI builder has left the picture. Traditional CMS platforms solve this by owning the whole stack, but that means migrating away from the generated repo, adding a database, or wiring up a headless API. None of that fits a site that was built in a few hours for a few hundred dollars. The overhead outweighs the project.
Some developers reach for Decap or a similar Git-backed CMS at this point, but that still requires configuration time and a level of setup that adds friction to what was supposed to be a fast handoff. The client still ends up with an interface that feels cobbled together, and the developer still has to maintain the integration.
What the Handoff Actually Needs
What the situation calls for is something that connects to the existing repo, gives the client a clean way to edit the content that’s already there, and commits changes back through Git without requiring the developer to redo the architecture. The content stays in the files. The deployment pipeline stays the same. The client gets a safe editing surface that won’t let them break the layout.
Mergeline fits here because it’s designed to be added after the build, not before it. Point it at the repo the AI builder produced, and it creates a Git-backed editing layer on top of whatever content structure is already in place. The developer doesn’t change the stack. The client doesn’t see the repo. Every edit is a commit, so nothing is ever silently overwritten and rollback is always available.
The broader pattern is worth paying attention to. AI site builders are compressing the build phase to the point where the post-launch content workflow is now the dominant operational concern on most small projects. The site is the easy part. What happens on day thirty, when the client wants to update the team page, is the part that determines whether the project stays low-maintenance or becomes an ongoing support burden. Planning that part before the client asks is the difference between a clean handoff and a recurring inbox problem.