Lovable Moved Its Own Site Off Next.js. The 98.5% Figure Is the Story.
Synergised Consulting Ltd
Last Updated: 2026-10-25
Lovable, the platform behind 70 million AI-built apps, has moved its own website off Next.js so that it now runs on the same server-rendered hosting as every app its users generate. The migration is genuine engineering news. The number an owner should look at is different one: after Lovable began pre-rendering its users' existing apps for crawlers, traffic from AI tools such as ChatGPT and Perplexity rose by 98.5%, against 2.9% for ordinary organic search.
What Lovable actually changed, and why it bothered
Lovable's own website, lovable.dev, carried 42 million monthly unique visitors, close to 400 routes and more than 910,000 lines of non-generated code when the company migrated it from Next.js on Vercel to TanStack Start, hosted on Lovable's own platform [1]. Every app published on that platform, including now its own front door, runs as a worker in a V8 isolate on Cloudflare's runtime, served by the same loader that handles more than 60 million user-built apps. Fewer than 200 lines of code are unique to the lovable.dev serving path [1]. The company's co-founder and CTO, Fabian Hedin, explained the platform side of this in a talk at Cloudflare Connect in San Francisco on 20 October 2026, published by Cloudflare's developer account on 23 October, which put the platform's total at 70 million AI-generated apps created [2]. The Connect programme listed the talk itself under its final title, "TanStack Start on Workers: Server-rendering apps an AI just wrote" [4].
The stated reasons are about ownership of the whole stack rather than performance. Lovable wanted to experience what its users experience, to push the limits of serving one very busy app on infrastructure built for millions of quiet ones, and to feed everything it learns back into the agent that writes its users' apps [1]. The change had actually been building for months: from 13 May 2026, every new project on the platform is generated as a server-rendered TanStack Start app, and existing projects received crawler pre-rendering without being migrated [3].
What server rendering actually changes
A client-rendered app answers the first request with a near-empty HTML shell and lets the visitor's browser build the page from JavaScript. A server-rendered app sends finished HTML immediately. Lovable's own engineering post illustrates the difference with its own numbers: switching between the two frameworks mid-session forced a full document reload costing around 5 seconds of median load time, against roughly 1.5 seconds for navigation that stayed inside one framework [1]. Human visitors mostly tolerate the shell-and-wait pattern. Readers that do not run JavaScript, which is the next section's subject, never see the page at all.
The 98.5% number: what it does and does not claim
When Lovable turned on pre-rendering for existing apps, serving fully formed HTML to verified crawlers while human visitors kept the normal app, it reported two platform-wide movements: a 2.9% increase in organic search traffic and a 98.5% increase in traffic from AI tools such as ChatGPT and Perplexity [3]. The size of the gap between those two figures is the finding. Google had already learned to wait for JavaScript; the AI assistants, which summarise rather than rank, largely had not. A page they could not parse was a page they could not cite.
The claim's limits matter as much as its size, and Lovable states them itself. These are early results measured across all of the platform's domains, not a controlled experiment and not a promise for any individual site [3]. The company does not publish the measurement period or the denominators, and a 98.5% increase on a small base is a different thing from one on a large base. The defensible reading is directional: server-rendered HTML changed AI-tool visibility by a large multiple, on a platform of tens of millions of sites, while conventional search barely moved.
The same page, seen two ways
The distinction is easiest to see concretely. Open a client-rendered page and view its source: the HTML contains a title, a script tag and little else, and the paragraph you wrote sits in a JavaScript bundle. Now open a server-rendered page and do the same: the paragraph is in the HTML itself, readable by anything that fetches the address. Nothing about the design, the words or the hosting contract changes between the two; only who can read the first response does. That is the entire substance of the 98.5%.
Who reads your website has quietly changed
Google's crawler does render JavaScript, but recent measurements cited by Lovable put the median delay between crawling and rendering at around 10 seconds, with a long tail stretching to hours [3]. The newer class of readers does not. An AI assistant answering a question about your market fetches the page, parses the HTML it received and moves on; if the content was still behind a script tag, the assistant's answer was built without you. Visibility now depends on what arrives in the first response, and that is a property of how the site is rendered, not of how well it is written.
This matters more for some pages than others, and the split is straightforward. Anything that should be found, a services page, a price guide, a post like this one, belongs in the first response. Anything behind a login, a dashboard or a checkout gains nothing from being crawler-readable and should stay private. Lovable's own documentation of its stack makes the same split at route level: routes that do not depend on per-request data can be pre-rendered to flat HTML at deploy time, while the rest render on demand [3].
A check you can run this afternoon
The practical check costs nothing and needs no vendor. Open your site's five most important public pages, view each page's source, and ask one question per page: is the actual content, the paragraphs a customer would read, present in this HTML? Record the result per page with the date. Where the answer is no, the content is invisible to every reader that does not run JavaScript, whatever the site looks like in a browser. Where the answer is yes, the site is already speaking the language the newer crawlers read.
The outage Lovable published alongside the migration
The migration was not clean, and Lovable's account of its own incident is the most useful part of the story. During the rollout of its dashboard, with traffic moved from 5% to 20% of users on a Friday, the error rate rose from 0.1% to around 50% within minutes, and the incident lasted 11 minutes [1]. The cause was not the framework and not the rollout itself: a few megabytes of static data for an unrelated feature, switched off behind a flag, pushed each worker over its runtime's memory limit. Rollback was fast; understanding came later.
The structural point survives the embarrassment. On this platform every app is an isolated V8 sandbox that starts in anything from 4 milliseconds to a second depending on its bundle size [1], and that economy has a hard memory ceiling attached. Code that used to live on a roomy server, bundled into the browser where it was harmless, becomes fatal when it ships in a server bundle under a fixed limit. Faster builds, down from 12-plus minutes to 6 to 9 in Lovable's case, and a 49% better median response time came with the new stack [1], but the memory discipline had to come with them.
What agent-written code changes about hosting
Most of Lovable's users never chose this architecture; their apps are generated into it. That is the quiet shift worth naming. When software is written by an agent, the hosting model is chosen by the platform, not the author, and the owner inherits whatever isolation, limits and failure modes the platform picked. The honest conclusion is that the failure modes change shape rather than disappear: a memory ceiling replaces a forgotten server, and an 11-minute, fully-rolled-back incident replaces a slow overnight degradation nobody watched.
What an owner should take, and what to leave alone
Leave the migration alone. Lovable moved its own site to dogfood its platform and to serve one website with 42 million monthly visitors; a business site with different traffic and different systems has no reason to follow a platform company's internal architecture decision [1]. The transferable parts are cheaper than a rebuild, and they are checks rather than purchases: confirm what your pages actually serve to a non-JavaScript reader, keep the pages that should be found in the server's first response, and know what your site runs on before anyone changes it.
The same reading discipline applies to the 98.5%. It is a platform-level early result with unpublished denominators [3], strong enough to take the direction from and too thin to put in a business case. The number that matters more is the one only you can produce: the page-source record from your own site, dated, showing what a crawler receives today. That is the baseline any later change gets measured against.
In our discovery workshops, owners almost never know how their own website is rendered; the question is not one they have been asked, and the answer takes five minutes to establish together. This is the same instinct the method applies everywhere: the workflow of high value here is not migration, it is measurement. What gets recorded is what a crawler receives per page and when that was checked, which is the artefact that turns a marketing figure like 98.5% into a question with a local answer: does my site show up in the first response, yes or no?
Sources
- [1] Lovable, "How we migrated lovable.dev away from Next.js and turned it into another Lovable app", Alexander Lebedev, published 18 August 2026:
- [2] Cloudflare Developers, post publishing Fabian Hedin's Cloudflare Connect talk, 23 October 2026, stating 70 million AI-generated apps created on Lovable's platform:
- [3] Lovable, "Building apps using TanStack Start", Fabian Hedin, published 1 June 2026, source of the 2.9% organic and 98.5% AI-tool traffic figures for pre-rendered apps:
- [4] Cloudflare Connect 2026, session listing for "TanStack Start on Workers: Server-rendering apps an AI just wrote", Fabian Hedin, 20 October 2026, Moscone West, San Francisco:
