COMPARE · FRAMER VS NEXT.JS
Framer or a custom Next.js build
Framer is right while the site is a marketing site that non-developers publish to. A custom Next.js build is right once the site needs application behaviour: authentication, dynamic data, calculators, integrations, or content generated from your own systems. Crossing that threshold early costs you publishing speed and gains you nothing.
THE THRESHOLD
There is a specific line, and it is not about size or ambition. It is this: does the site say things, or does it do things?
A site that says things — explains a product, tells a story, lists case studies, publishes a blog — belongs in a builder, however good your engineers are. A site that does things — authenticates, calculates, reads from your database, generates pages from data you own — is software, and software belongs in your codebase.
Most startups cross this line later than they think, and rebuild earlier than they should.
WHAT CROSSING EARLY COSTS
Publishing speed, mostly. In a builder a founder changes a headline at midnight before a launch. In a custom build that same change is a branch, a review, a deploy, and a developer who was doing something else.
THE PATTERN WE SEE
A team rebuilds the marketing site in Next.js because it feels more serious, and six months later the copy is stale — not because anyone decided it was fine, but because every change costs a developer's afternoon. The site quietly stops being maintained, and the thing that was supposed to be more capable ends up less current.
WHAT YOU GAIN
If two or more of those are on your roadmap for the next six months, build custom now and skip the intermediate step.
THE HYBRID
The setup that suits most companies is not either one. Product and app on your own stack, marketing site in a builder, joined on one domain by a proxy or a subdomain.
Marketing ships pages without opening a pull request. Engineers never get asked to review a copy change. And the day the marketing site genuinely needs application behaviour, you already have somewhere to put it.
This site is the other version of the same argument: it started in Framer, and moved to a Next.js codebase only once we wanted MDX content, custom schema and control we could not get otherwise. That is the threshold being crossed for a real reason rather than a feeling.
QUESTIONS
When should a startup move to a custom build?
When the site needs to do something rather than say something: log people in, calculate a result, read from your own database, or generate pages from data you own. Also when the marketing site and the product have merged into one surface, which happens with self-serve products.
Is a custom site better for SEO?
Not inherently. It gives you total control over rendering, metadata and structured data, which matters at scale — thousands of programmatic pages, complex internationalisation. At twenty pages that control buys you nothing you did not already have.
What does going custom actually cost?
The build is the smaller half. The real cost is that every future content change goes through a developer and a deploy, unless you also build a CMS layer — which is more work, and now you own that too.
Can we run both?
Yes, and it is often the right answer: the product on your own stack, the marketing site in a builder, on the same domain via a proxy or a subdomain. Marketing publishes without touching the codebase, and engineers never review a copy change.