Lovable Moved 70 Million AI-Built Apps Off Next.js: What the 98.5% Lift Means

Last Updated: 25 October 2026

On 23 October 2026, Cloudflare published Fabian Hedin's talk from Cloudflare Connect, the one where Lovable's co-founder and CTO explains how his company moved from Next.js to TanStack Start on Cloudflare Workers. The post has 178,295 views and 1,289 likes as of 25 October 2026, which is modest by launch-post standards and yet it describes one of the largest framework migrations in the AI era: 70 million AI-generated apps on one platform, 60 billion requests a month, and a 910,000-line website that now runs like any customer's project.

The migration story is worth reading for the engineering. The number worth acting on is different. It is 98.5%, and it is about who can read your site at all.

What Lovable actually changed

Lovable's flagship site, lovable.dev, moved from a Next.js app hosted on Vercel to TanStack Start served by Lovable's own platform on Cloudflare Workers. The site carries 42 million monthly unique visitors, close to 400 routes and 910,000 lines of non-generated code, including a small in-browser IDE. The move took six months. Both frameworks ran side by side behind a proxy worker, and traffic switched route group by route group. According to Alexander Lebedev's engineering post, fewer than 200 lines of code are now unique to the lovable.dev serving path.

Three reasons drove the decision. The first is dogfooding: Lovable wanted its own front door to feel every hosting bug its users feel. The second is single-app scaling. Lovable was already good at hosting tens of millions of small, low-traffic apps, and supporting tens of millions of visitors on one app is a different problem. The third is the builder agent. One uniform stack means every internal lesson can be fed back into the AI that generates customer apps.

On stage, Hedin put the search problem ahead of the engineering ones. According to his Cloudflare Connect talk, "the main reason that made us really make this migration is that we wanted to have the best possible SEO for our users." He also described the shape that makes the platform work: one codebase deployed as a server bundle and a client bundle, with each route declared static or dynamic, so a page that needs nothing dynamic still gets served as plain static content.

Layer	Before (Next.js on Vercel)	After (TanStack Start on Workers)
Framework	Next.js	TanStack Start (TanStack Router)
Runtime	Vercel hosting	Cloudflare Workers, one Worker per app
Rendering	Mixed, server and client	SSR, SSG or CSR per route
Server logic	Next.js server functions and routes	TanStack server functions, transformed at build time
Secrets	Environment configuration	Workers bindings, rotated without a redeploy
Deployment	Vercel pipeline	Same app loader worker as 60 million customer apps

The result that matters commercially: lovable.dev is now just one more bundle among the 60 million or so apps the platform serves. Every hosting improvement Lovable makes for itself reaches its users by default.

The 98.5% number: why server rendering is now an AI visibility problem

A client-rendered React app sends back a near-empty HTML shell on the first request: a root div and a script tag. The browser downloads the JavaScript, executes it, then fetches the data, so two round trips happen before anything appears. Crawlers that do not execute JavaScript see an empty page. Google does eventually render it, with a median delay Lovable puts at around 10 seconds and a long tail stretching to hours. Social previewers on LinkedIn, Slack, WhatsApp and X read meta tags straight from the HTML, so a client-rendered app shows a generic card even when its per-page tags are perfect.

Lovable fixed that for existing apps without migrating them. When a verified crawler visits a deployed app, Lovable renders the page server-side in a headless browser and serves the finished HTML. Human visitors still get the ordinary single-page app. Across all domains, Lovable reports organic search traffic up 2.9% and traffic from AI tools such as ChatGPT and Perplexity up 98.5%.

That second figure is the one to sit with. Answer engines are not patient renderers. They fetch, parse and quote what they can see, and a page whose content arrives only after JavaScript runs is a page they cannot cite. In our own answer engine optimisation work at Flowtivity, the first audit step is always the same: fetch the raw HTML with JavaScript disabled and read what is actually there. On a client-rendered marketing site, the answer is usually a title tag and not much else.

How 70 million apps run on one platform

Every published Lovable app is built as its own Worker for Cloudflare's workerd runtime. A single entry worker serves all of them: it loads the app's code, creates a worker dynamically, and dispatches the request into that worker's own V8 isolate. Isolate instantiation costs roughly 4 milliseconds for a small bundle and up to a second for a huge one. Isolates are cached and reused, so that cost is paid rarely, and a healthy isolate serves between 500 and 10,000 requests before eviction, mostly depending on how often you deploy.

Cloudflare's own framing is that cold starts are effectively zero, because a Worker loads in about 5 milliseconds and the average network round trip to Cloudflare is longer than that. Lovable's numbers are the honest version of the same claim: cheap for small bundles, not free for large ones, and always bounded by a hard 128 MB memory ceiling per isolate. At 60 billion requests a month and more than a million new apps a week, the platform's job is keeping isolate churn low enough that the cache does the work.

The 11-minute outage: where agent-written server code breaks

During a dashboard rollout to 20% of users, Lovable's error rate climbed from 0.1% to 0.5%, then to about 50% within minutes. The incident lasted 11 minutes. The trigger was not the dashboard at all. A few megabytes of static JSON, added for an unrelated feature that was switched off, pushed each worker over the 128 MB limit. Isolates that normally served 500 to 10,000 requests were dying after fewer than 10, and every request in flight died with them.

The fixes are the useful part. Parsing multi-megabyte JSON inside request handlers instead of at module level cut memory use by 2x to 12x depending on the route, because module-level objects live in server memory forever. Stubbing client-only code out of the server bundle saved about 9 MB of bundle, which translated to 18 MB of worker memory, because V8 stores the whole string in a two-byte format once it contains a single character outside Latin-1. Lebedev's own summary of the root cause is refreshingly blunt: he did not measure baseline memory, and he accepted a 0.1% error rate as something to fix later.

That is the pattern to watch when agents write your server code. Agents are good at producing plausible code quickly, and memory behaviour is invisible until it is an outage. A baseline measurement, taken before launch, would have caught it.

Six months, one developer, 910,000 lines

Alexander Lebedev started the migration alone, looking at 350,000 lines of code he had never read. Six months later the app was past 850,000 lines, and another 60,000 have landed since. Agents drafted the pull requests and he reviewed and landed them in batches, so no feature team ever received a share of the migration work. The original plan, distributing tickets across the teams who owned each feature, collapsed in the best possible way.

Two engineering choices carried the project. The first was running both frameworks in parallel behind a proxy worker that decided, per route and per user, which one served the request. Crossing between frameworks forces a hard navigation, about 5 seconds against roughly 1.5 seconds for a soft navigation, so routes were grouped by user journey and each group rolled out from internal testing to 1% and then to 100%. The second was a shared-code discipline: a single #shared/ alias wired into both frameworks, lint rules forbidding any Next.js or TanStack import inside it, and an agent-powered portability check on every merged pull request. At the end, 97% of the web codebase was framework-agnostic and 3% was Next.js-specific.

The payoff beyond dogfooding was measurable. Median time to first byte fell 49%, and the long tail, initially up to twice as slow, is now 16% better than before. Production builds dropped from more than 12 minutes to 6 to 9 minutes, which matters when your company deploys hundreds of times a day. Locally, the Vite dev server starts in 10 seconds with 1.5 GB of RAM against 70 seconds and 8 GB for Next.js 16.2 with Turbopack on the same M4 Max, and some colleagues had reported 20 GB or more. Next.js 16.3 now claims up to a 90% cut in dev server memory, which is a fair counterpoint and a reminder that these numbers move.

Why the agents did better on TanStack Start

Lebedev says his agents performed better on TanStack Start than on Next.js, and his explanation is about training data rather than framework quality. Next.js versions 12, 14 and 16 differ enough that advice written without a version is actively misleading, so agents reach for page-router patterns in an app-router project or assume caching defaults that no longer apply. TanStack Start is new enough that its corpus is smaller and more consistent, and Lovable injects a curated set of TanStack rules into every new-stack request, built with the TanStack team's own AI guidance as a starting point.

"A small but consistent training corpus beats a large one full of internal contradictions," Lebedev writes. "An agent can fill a knowledge gap by reading the docs and the surrounding code, but it can't easily unlearn a confidently wrong habit."

He also raised the abstraction level of the work. Instead of tracking migration tickets one by one, he defined a measurable metric, such as how many agent tools still had a Next.js user interface, wrote a script to count it, and fed that to a planner agent that proposed batches of up to 12 pull requests at 800 to 1,600 lines each. Implementation agents executed the batches, the metric dropped, and the loop repeated. That pattern is worth stealing even if you never migrate a framework.

What Australian teams should copy, and what to leave alone

The migration itself is not the lesson. Lovable's reasons exist at its scale: it runs a hosting platform, it needs one uniform target for its builder agent, and it employs the people who operate the infrastructure. A team of eight copying this over a quarter with normal deadlines would get the outage paragraph and not the happy ending. The transferable parts are cheaper.

Render what machines need to read. If a page matters for search or for AI citation, its content should exist in the HTML on first response. Prerender the routes that every visitor sees the same way, and verify it the boring way: fetch the page with curl and read what comes back. Lovable's 98.5% lift in AI-tool traffic came from exactly this, applied to apps that had not changed frameworks at all.

Keep the framework-specific layer thin. Lovable targeted 5% to 10% framework-specific code and landed at 3%. You do not need a migration planned to want that shape. A shared folder, an import alias, lint rules that forbid framework imports inside it, and adapters behind TypeScript path aliases give you most of the benefit, and they make testing easier today.

Measure baseline memory before launch. The 11-minute outage was caused by a few megabytes nobody accounted for. Whatever your runtime, a simple before-and-after memory check on your heaviest routes is cheaper than a Friday afternoon incident.

Make rollouts reversible and deterministic. Lovable ran one external rollout at a time, kept users sticky to the framework they first landed on, and built a way to pin feature flags in tests so results were not affected by random percentages. Reversibility is the actual safety net when agents move faster than your tests can follow.

The same lesson shows up on the model side. In our dual DGX Spark testing, DeepSeek V4.1 Flash serves about 35 tokens per second on a single stream and 62 tokens per second across four concurrent streams. What limits how many agents we can run in parallel is memory and scheduling, not model quality. Whether the compute is a 128 MB isolate or a 128 GB local cluster, the constraint moves to the infrastructure around the model once the model is good enough.

Frequently asked questions

Did Lovable leave Next.js?

For its own website, yes. lovable.dev moved from Next.js on Vercel to TanStack Start on Lovable's own platform in August 2026, after a six-month migration. Lovable's users were affected earlier and differently: from May 2026, new projects were created as server-rendered TanStack Start apps, while existing projects kept running as client-rendered single-page apps and gained pre-rendering for crawlers.

Why did Lovable migrate from Next.js to TanStack Start?

Three reasons, according to Lovable's engineering post: dogfooding its own hosting platform, pushing single-app scaling to tens of millions of visitors, and giving its builder agent one uniform stack to learn from. On stage at Cloudflare Connect, CTO Fabian Hedin named search visibility as the main driver, saying Lovable wanted the best possible SEO for its users. The measurable side effects were a 49% lower median time to first byte, builds down from 12+ minutes to 6 to 9 minutes, and a dev server that starts in 10 seconds with 1.5 GB of RAM instead of 70 seconds with 8 GB.

Does server-side rendering improve AI search visibility?

Lovable's own numbers say yes. After adding pre-rendering for existing apps, it reported a 2.9% increase in organic search traffic and a 98.5% increase in traffic from AI tools such as ChatGPT and Perplexity. The mechanism is simple: AI crawlers and social previewers read the HTML they receive, and a client-rendered app gives them almost nothing.

What is the memory limit for a Cloudflare Worker isolate?

In Lovable's setup, each app runs in a V8 isolate with a 128 MB memory ceiling. Going over it kills the isolate and every request in flight, which is how a few megabytes of static JSON turned a 0.1% error rate into roughly 50% in minutes. The limit is a property of Lovable's worker configuration, not a universal number for every Cloudflare deployment.

How many apps has Lovable generated?

Cloudflare's 23 October 2026 post put the figure at 70 million AI-generated apps, up from the 60 million Lovable cited in August 2026. The platform creates more than a million new projects a week and serves about 60 billion requests a month, across apps that together attract close to a billion views a month.

Should a small business migrate off Next.js because of this?

No. Lovable's migration made sense for a company that runs a hosting platform and needs one stack for its agent. For most teams the useful actions are server rendering, a thin framework layer, a memory baseline and reversible rollouts, none of which require changing frameworks.