Summarize with AI
Framer vs Next.js comes down to one test: does a page on your marketing site need to run your product's code? If it does, like a live playground, docs built from your API, or pages that change for a signed-in user, Next.js earns its place for those pages. If it does not, Framer wins, because the people who need to change the site can change it the same afternoon without opening a pull request.
This matters most for an AI startup that already has engineers. Code feels free when the team writes it all day, so the website ends up in the repo by default. Then the founder and the growth lead, the two people who hear what the market is saying this week, become the two people who cannot edit the page that says it. A stranger decides what kind of company you are in about four seconds. That page should move as fast as you learn.
Eleven pages and one box that runs real code
Picture a devtool startup of nine people. The product is an AI agent that writes unit tests for TypeScript code. The marketing site has 11 pages: Home, Pricing, Customers, Security, Changelog, Blog, About, Careers, Docs, and two comparison pages.
The homepage has a playground. On the left is an editor, prefilled with a small function called applyDiscount(cart, code). Under it sits one button, Write tests. Press it and the right panel fills in: 7 tests, 6 passing, 1 failing. The failing test has a note in plain English: the code SAVE10 is applied twice when the cart is updated. That box is the best salesperson the company has. It calls the real model, through the real API, with a rate limit so nobody burns through inference for free.
The engineers want the whole site in the monorepo, next to the app, sharing the design tokens and the button component. The head of growth wants a new landing page for every campaign: one for the Python beta, one for a conference booth, one for each competitor that ships a feature. She does not want to file a ticket for each of them.
Who opens a pull request to change a headline
Most Framer vs Next.js comparisons line up features: speed, SEO, CMS, animations, price. That misses the real question. The real question is who changes the site on an ordinary Tuesday, and how long it takes.
In the version where the site lives in the repo, here is what the founder's week looks like. The growth lead files a ticket called New page: /python-beta, launch Thursday. It sits in the backlog behind a bug in the product. The founder writes the hero copy in a doc, then pastes it into a pull request comment because he cannot run the site locally. An engineer changes one sentence on the pricing page and the change waits for two approvals and a full test run built for the app. The conference passes. The page ships the week after.
Nobody on that team did anything wrong. The site just ended up owned by the people with the least reason to change it. Here is the claim most engineering teams will push back on: wanting the site in the monorepo is usually about the engineers' comfort, not the site's job. The site's job is to tell a stranger what this product does, in words that change every few weeks as you learn which words work.
The three pages where Next.js actually wins
There are real cases where code is the right home for a page. All three involve running something from the product.
- A playground that calls your product. If the demo needs auth, rate limits, server secrets or a sandbox, it is product code. It belongs where the product engineers can test and deploy it.
- Docs built from your source. Reference pages generated from an API schema or from code comments should be built in the same pipeline as the code. Otherwise they drift the first week someone renames an endpoint.
- Pages that know who is looking. A pricing page that shows a signed-in team its current plan and usage is part of the app, not the marketing site.
Notice what is not on the list. The homepage hero, the pricing table for strangers, customer stories, the changelog, the careers page and every campaign page. None of those run product code. Even the playground can often stay inside Framer. Framer supports code components, which are React components written in Framer's own code editor, and its developer tools add overrides, API endpoints designers can use, and a server API for automating publishing. An engineer can build the Write tests box as one component that calls a public endpoint, and the growth lead can move it around the page like any other block.
Editing, CMS, speed and search, side by side
Editing. In Framer, the growth lead edits the layout on a canvas. With on-page editing, a teammate with Content permissions can open the live site and change text, images, component properties and CMS content. Those edits are reviewed and published by someone with publishing permissions, so nothing goes live by accident. In Next.js, every edit is a code change unless engineers connect a headless CMS, which is one more system to pick, wire up and pay for.
CMS. Framer has a CMS built in for the blog, changelog and customer stories. In Next.js the CMS is your choice, which is freedom if you have opinions and a project if you do not.
Speed. Both can be fast. A Next.js site is as fast as what your engineers ship into it, and a heavy client bundle copied from the app makes marketing pages slow. Framer handles the hosting for you, so speed depends more on how many large images and animations the page carries.
Search. Both give you control of titles, descriptions, URLs and redirects. The gap that matters is not a ranking factor. It is how fast you can publish a page for a query you just found. A team that ships a comparison page in an afternoon will out-publish a team that ships one a sprint.
Running Framer and Next.js on one domain
You can have both. Keep the marketing pages in Framer and put the playground or the docs in Next.js. Framer's own guide says the simplest setup is subdomains: the site on your main domain, the docs on docs.yourdomain.com, the app on app.yourdomain.com. Serving a Framer section at a path on a domain that another host runs is possible too, but Framer lists it as needing a Pro plan with the Advanced Hosting add-on, or Enterprise.
Going the other way, Next.js can take the whole domain and pass some paths to another app. Its multi-zones guide uses rewrites to send each path to the right origin. Two details from that guide matter for a marketing site. Moving between zones is a full page load, not an instant switch. And links that cross zones should be plain anchor tags, not the Next.js Link component. We covered the route by route split, and what breaks in the sitemap and analytics, in our guide to a visual builder as the front for a Next.js product. The same rules hold with Framer in Webflow's place.
Pick by team shape, not by tool
- Founder plus engineers, no marketer yet. Framer. The founder is the one rewriting the hero, and he should not need a terminal to do it.
- Engineers plus a growth lead who ships campaigns. Framer for the site, with the playground as a code component or on its own subdomain.
- Docs are the product's front door. Framer for the marketing pages, Next.js for docs on a subdomain, built from the same repo as the API.
- Most pages read live product data or change for signed-in users. Next.js, owned by an engineer who has time on the calendar for it. If nobody does, you want outside help, and our ranking of Next.js development agencies for AI devtools is a place to start.
A devtool does not need a coded site to look like a devtool. Dualite, an AI builder whose users ship real code, runs its website on Framer. We designed and built that site in Framer, and our product work for them happened inside the product itself. For the same decision with Webflow in the frame, read Webflow vs Next.js.
The engineer hours nobody books against the site
A coded marketing site has no invoice, so it looks cheap. Its cost shows up in the sprint. Every copy change, every new page, every dependency update and every broken build on the marketing app is time an engineer did not spend on the product.
That product has a bar to clear. Measured on AI companies, the Series A bar is around 3.5 million in ARR, up from roughly one million three years earlier (Carta, Q1 2026). Across all sectors, the median gap from seed to Series A is around 616 days. Inside that window, an engineer week spent on a campaign page is a week the product did not get closer to the number the raise is priced on. It is also a week the site kept saying last month's story.
What to do this week
- List every page on the site. Next to each, write yes or no: does it run product code?
- Count the yes pages. If it is zero to two, the site belongs in Framer and the yes pages can sit on a subdomain or inside one code component.
- Look at the last ten changes to the site. Write down who asked for each, who made it, and how long it waited.
- Ask the growth lead which page she would ship tomorrow if she could. If the answer comes fast, the bottleneck is the stack, not the ideas.
- If you stay on Next.js, name one engineer as the site owner and give that person a fixed slot each week. Unowned code is the worst of both options.
At Studio Maydit we build in Framer, Webflow and custom code, so we have no reason to push one. For most AI teams at this stage, the right answer is a Framer site the founder can edit, with the parts that run product code kept where the engineers live. A fixed-scope project runs three to four weeks. If you want an outside read on which of your pages actually need code, book a 30 minute call with Studio Maydit.
