The short version
You pasted a link to your app into Slack and it came out as a blank grey rectangle. Or you searched for your own product and found nothing, in Google and in ChatGPT both. So you went looking for what Lovable actually builds, found half a dozen articles agreeing it is a React single-page app on Vite, and worked out from there that you need a rebuild in Next.js. That conclusion is where most people land, and it is usually wrong now.
Here is the whole answer before the detail. Lovable's own FAQ says that apps created from 13 May 2026 use TanStack Start with server-side rendering, and that older apps use React and Vite. Lovable does not generate Next.js in either case. So the real question is not which framework is better. It is which side of that date your project sits on, and that takes about two minutes to check.
If your project is on the newer template, your pages are already rendered on the server and there is nothing to fix. If it is older, Lovable documents an upgrade you can run yourself from inside the product, and version history can undo it. A large share of readers need no help from anybody, and some need to do nothing at all.
Why does everything you have read say Vite?
Because it was true, for a long time, and the internet has not caught up. Lovable's upgrade documentation is direct about the change, describing TanStack Start as "Lovable's latest template" and the previous arrangement as "React + Vite stack, the stack Lovable used before TanStack Start". The FAQ puts a date on it: "New Lovable apps created from May 13, 2026 use TanStack Start with server-side rendering (SSR). Older apps use React + Vite."
Now compare that to what currently ranks. Tool-review sites, agency blogs and the usual Medium write-ups all describe the Vite single-page app as the current default. Several were published or updated well after May. None of them carries that sentence.
There is a tell worth knowing about, because it tells you how carefully that whole tier is maintained. Some of those same pages state which AI models Lovable orchestrates, and name models that have since been superseded. A page that is stale on the model list is usually stale on everything else too. We are not going to repeat that particular claim here, for reasons in the FAQ below.
We are pointing this out for a practical reason rather than a rhetorical one. If you researched this last week and reached a confident conclusion about your own app, the research was reasonable and the conclusion may still be wrong. Worth re-checking before you spend anything on it.
So what does Lovable generate today?
Layer by layer, for a project created on the current template.
The framework is TanStack Start, with server-side rendering. That is the headline change and everything else on this page follows from it. Routing, data loading and the server entry point come from that framework rather than from a client-side router bolted onto a static bundle.
The language is TypeScript and the UI is React. That has not changed and it is the reason the ownership question has a comfortable answer. Whatever else moved, the code is still ordinary React that an ordinary React developer can read.
Styling is Tailwind CSS, which Lovable's FAQ confirms directly.
The backend is not really Lovable's at all. The FAQ describes backend functionality arriving through Lovable Cloud, your own Supabase project, or third-party APIs. Lovable Cloud is itself built on Supabase, with Lovable holding the account rather than you. If that distinction matters to you, and it should if you hold customer data, we wrote about what that means and what the export leaves behind in Lovable Cloud vs your own Supabase.
Hosting is Lovable's own, described in its publishing documentation as hosting the published app for you with "no servers to set up, and HTTPS included". Site metadata, meaning the title, the description and the favicon, is generated during the build.
If your project predates 13 May 2026 and you have not upgraded it, replace the first item with React on Vite and leave the rest as it stands. The backend, the styling and the language did not change.
Does Lovable use Next.js?
No. Lovable's documentation states plainly that generating Next.js is not supported, and that has stayed true across the template change. Asking it nicely in a prompt does not change what the platform scaffolds.
This matters more than it looks, because of where the question usually comes from. Somebody reads that their app is a single-page app, learns that single-page apps have historically been awkward for search engines, and reaches for Next.js because Next.js is the framework people name when they say server rendering. The reasoning is sound. The premise is out of date.
If you genuinely need Next.js, for reasons of your own rather than for SEO, then you are not upgrading a Lovable project. You are exporting the code and leaving the platform, and that is a real piece of work rather than a switch. Be honest with yourself about which of those two things you are actually trying to do, because they have very little in common.
How do you tell which stack your project is on?
Do not take our word for it and do not take the date on any article, including this one. Look at your own project. Lovable's documentation describes a code editor, reached from the Code tab, where the left panel shows your file structure and you can search across the whole project.
Open it and look at the root of the file tree. A vite.config file sitting at the top level means you are on the older React and Vite stack. A project on the current template carries the TanStack router and server entry files instead, and no Vite config at the root. That single file is the fastest reliable answer.
Cross-check with the creation date. If you started the project before 13 May 2026 and never ran the upgrade, you are on the older stack regardless of what you think you remember choosing. Nobody chose this. It was the default at the time.
The confirming test takes ten seconds and needs nothing but a browser. Open your published site, right-click, and choose View Page Source. That shows you what the server actually sent, before any JavaScript ran. If you can see your real headline and your paragraph text in there, you are being served finished HTML. If you see a mostly empty shell with a script tag and nothing readable, your page is being assembled in the visitor's browser after the fact.
That last test is the one that matters, because it measures the thing you actually care about rather than the label on the framework.
Why does this decide whether Google and ChatGPT can read you?
When a page is server-rendered, the server does the work of turning your content into finished HTML and sends that. Whoever asks for the page gets the words. When a page is a client-rendered single-page app, the server sends a near-empty shell plus a bundle of JavaScript, and the words only exist after that JavaScript has downloaded, parsed and run inside a browser.
Everything downstream comes from that one difference. Lovable's own upgrade documentation states the benefit without hedging: server rendering means everyone receives "the same complete page, every time: visitors, search engines, AI crawlers, link preview bots, and any other tool".
Be careful about the Google part, because this is where a lot of advice overstates the case. Google does execute JavaScript, and a client-rendered app can and often does get indexed. It happens in a second pass, it is slower, and it is less reliable for pages that change often, but it is not the wall people describe. If somebody tells you a single-page app cannot rank at all, they are selling you something.
The part that is genuinely different is everything that is not Google. Link preview bots, the ones behind Slack, WhatsApp, LinkedIn and iMessage, generally fetch your HTML and read the meta tags without running any JavaScript. If your title and description only materialise client-side, those bots find nothing, which is exactly why your link pastes as a blank rectangle. The same broadly applies to the crawlers feeding AI answer engines. They are optimised for volume, and executing a full JavaScript bundle for every URL is expensive.
So the honest framing is not that a client-rendered app is invisible. It is that a client-rendered app is legible to the one crawler that invested heavily in rendering, and unreliable for the growing set of tools that did not. That set is where a rising share of product discovery now happens.
What it costs you to leave it
No invented statistics here. Just the consequences we can describe honestly.
Your public pages are unreliable in the places people increasingly start. If somebody asks an AI assistant for tools like yours and the crawler behind it could not read your pages, you are not in the answer. There is no ranking to check and no report to look at. You are simply absent, and absence does not show up in your analytics.
Your links look broken when people share them. Every blank preview is a share that carried less than it should have, at the exact moment somebody was recommending you.
You cannot describe your own codebase. This one costs you in a hiring conversation. Walking into it unable to say what the app is built on reads as not knowing what you own, which is a much worse impression than the truth, which is that the platform changed its default and nobody sent you a note.
And the cost of the wrong fix is the largest of the three. The default conclusion from bad research is a rebuild. That is weeks of work, a migration off the platform, and a new codebase to maintain, in service of a problem that may already be solved or may be one in-product upgrade away.
Who does not need to do anything about this?
A lot of you, and it is worth being specific rather than gracious about it.
If your app lives behind a login, none of this applies. Internal tools, admin panels, dashboards, client portals, anything where the first thing a visitor meets is a sign-in form. Search engines were never going to index those pages and no crawler wants them. Server rendering buys you a slightly faster first paint and nothing else. Close the tab.
If you already checked View Page Source and your content was there, you are done. You are on the current template or you already upgraded. Nothing on this page is a task for you.
If your public surface is one landing page and you get customers from somewhere other than search, from a community, a marketplace listing, outbound, or an existing audience, then this is a low priority. Fix the link previews if they bother you and move on to something that actually moves your business.
And if you are pre-launch, do not touch it. Ship the thing. Find out whether anyone wants it. Rendering strategy is a problem you earn by having an audience, and optimising for crawlers before you have a product is the most comfortable way to avoid the harder work.
The group this genuinely matters to is narrower than the internet implies: public marketing pages, on the older stack, at a company where search and AI-assisted discovery are a real channel.
What actually breaks when you move to server rendering?
If you are on the older stack and the upgrade does apply to you, Lovable documents it as an in-product migration you can start from chat or from project settings. It inventories your pages, converts the structure, moves your metadata and analytics, carries the styling across and rebuilds. You do not need an engineer to press the button.
You may need one for what comes after, and Lovable's own documentation names the reason: "Some code libraries only work in the browser and can break server rendering."
That sentence is the whole risk in one line, and it is worth understanding rather than fearing. Code that runs on the server has no browser around it. There is no window, no document, no localStorage. A library that reaches for any of those the moment it loads will now be asked to run in a place where they do not exist, and it will fail. Charting libraries, map widgets, rich text editors, anything that measures the size of something on screen, and analytics snippets that expect a live page are the usual suspects.
The fix is rarely dramatic. Those components get loaded only in the browser rather than on the server, which is a normal and well-understood pattern. It is fiddly rather than hard, and it is the part of the job that tends to take longer than the migration itself.
Three practical notes from Lovable's documentation. Only one upgrade runs per project at a time, so you cannot parallelise it. The upgrade is reversible through version history, which is the detail that should lower your heart rate before you start. And if you shipped a progressive web app, cached versions on people's devices may need a manual follow-up, because their browsers are holding an old copy that does not know anything changed.
What decides the effort is not the size of your app. It is the count of browser-only libraries you pulled in, how much of your content is public rather than behind auth, how many pages carry their own metadata, and whether anything in your build reads from the window at import time. A ten-page marketing site with two chart widgets can be more work than a forty-page app with none. Once you know your own answers to those four, you know roughly what you are in for.
If your app is already live and taking real traffic, the sequencing advice from our production readiness guide applies here too. Do it on a branch, check every page, and do not upgrade on the day of a launch.
What do you own, and how do you get the code out?
Lovable's FAQ answers the ownership question about as plainly as a FAQ can. Asked who owns the projects and code it generates, the answer given is "You as the creator do!"
Getting it out is documented rather than improvised. You can download the codebase as a zip from the code editor or from project settings, and you can set up two-way sync with GitHub or GitLab so the repository is genuinely yours and stays current. That sync is the option to take if there is any chance of a developer joining you, because it turns the project into an ordinary repository with ordinary history.
What you get is not a proprietary export format. It is React and TypeScript with Tailwind, which is the same stack a large share of the industry uses. A developer who has never opened Lovable can clone it and be productive. That is the honest good news in this whole topic and it is the part nobody tells you while they are recommending a rebuild.
Which brings us back to the rebuild question, and our actual position on it. Nobody should be told to rebuild a working Lovable app because of its rendering strategy. If someone recommends that, ask them which specific thing about your app cannot be fixed in place, and ask them to name it. Sometimes there is a real answer. Usually the answer is that a rebuild is a larger, cleaner and more profitable piece of work for whoever is proposing it.
We have looked at a fair number of AI-built codebases at this point and we have not yet met one where the rendering strategy alone justified starting again. What we have met are apps with a genuine problem somewhere else entirely, usually in how the database is exposed, which is a different conversation and one we covered in what AI builders leave exposed. If you would rather have somebody else handle the whole path from working prototype to production, that is what our AI builder to production work is.
Frequently Asked Questions
What does Lovable use under the hood, Next.js or Vite?
Neither, if your project is recent. Lovable's FAQ says apps created from 13 May 2026 use TanStack Start with server-side rendering, and older apps use React and Vite. Next.js is not generated at all. Tailwind handles styling either way.
Why do most articles say Lovable builds a Vite single-page app?
Because it did for years and those articles have not been revisited. The stale answer is still the most widely published one, which is why people arrive at the wrong conclusion about their own project.
How do I tell which stack my project is on?
Open the Code tab and look for a vite.config file at the root of the file tree. Then open your live site and use View Page Source. If your headline text is in there, you are being served finished HTML.
Do I need to rebuild in Next.js for SEO?
Almost certainly not, and Lovable does not generate Next.js anyway, so a rebuild means leaving the platform. If you are on the older stack, the documented in-product upgrade is reversible through version history. Try that first.
Which AI models does Lovable use?
Lovable does not publish this. Articles that name specific models tend to be the same ones describing the pre-May stack as current, and the models they name have been superseded. We would rather say we do not know than guess.
Who owns the code, and can I export it?
You own it. Lovable's FAQ says so directly. Download it as a zip from the code editor or project settings, or set up two-way sync with GitHub or GitLab, which is the better option if a developer is joining you.
