We pressure-tested a Framer weekend rebuild for one of our marketing pages — here's what we learned

Most vøiddo marketing pages are still plain hand-coded HTML/CSS under our own control. We spent this weekend pressure-testing whether Framer is now good enough to justify moving one of those pages. This is not a fake migration victory lap. It is a real evaluation sprint: what now looks strong, what still looks expensive or risky, and why the live site you are reading is still not running on Framer.

Disclosure: the link above goes to Framer's public pricing page. We are not currently running a verified Framer partner link on this post, so there is no commission attached to this click today.

Why we re-opened the question

The case for Framer is not that hand-coded marketing pages are impossible. Ours load fast, sit in git, and do exactly what we tell them to do. The problem is operating cost. If a designer wants to adjust spacing, swap a hero line, or test a softer CTA on a Tuesday night, the current workflow still goes through someone comfortable editing the page by hand and pushing it safely.

That is tolerable when a studio ships one big product. It is noisier when the same team is shipping browser extensions, paid audits, landing pages, WordPress plugins, games, and whatever revenue wedge we are testing this week. The real question was simple: has Framer crossed the line where the workflow win outweighs the hosting, portability, and code-ownership costs for one marketing page?

What changed since the last time we looked

Framer's current public pricing is more nuanced than the old "nice tool, maybe later" impression we had in our heads. As of this update, the paid site plans visible on Framer's pricing page are roughly:

• Basic at roughly $10/month billed annually for smaller sites.
• Pro at roughly $30/month billed annually, with staging, roles/permissions, relational CMS, redirects, and higher limits.
• Scale above that for higher-traffic or more infrastructure-heavy setups.
• Extra editors billed separately, which matters more than the headline plan price if more than one person needs edit access.

That is materially different from the older snapshot many blog posts still repeat. It also changes the decision. The question is no longer "can Framer replace hand-coded HTML for a small team?" It can. The question is "how much are we willing to pay for that convenience once real collaboration seats are involved?"

What looks genuinely strong for a studio like ours

• Designer-owned iteration. This is still the entire case. If the goal is to let design change sections, spacing, and copy without turning every landing-page adjustment into an engineering task, Framer fits the problem.
• Staging and rollback. Pro now makes this much more operationally credible. A serious marketing page should not require "edit live and hope nothing breaks." Framer's staging story is better than it used to be.
• Roles and permissions. That matters once a studio stops being one person. We do not want everyone with the link editing production pages directly. The Pro plan explicitly addresses this.
• CMS and redirects on the same surface. For landing pages, case studies, lightweight changelogs, and content sections that are not a full publishing system, that is useful. It removes a small pile of maintenance work we currently just absorb.
• Hosting off our shoulders. There is real value in not thinking about nginx vhost drift, TLS renewals, or tiny front-end deploys for every headline change.

What still keeps us on hand-coded pages

1. Lock-in is still a real cost

If we move a page into Framer, we are not moving it into a neutral file format we can comfortably host anywhere later. We are moving it into Framer's system. That can be fine for a stable marketing page. It is less fine if the page later becomes a hybrid marketing/product/docs surface that we want deeply integrated with our own stack.

2. Extra editor pricing changes the math quickly

The plan headline is not the whole bill. One paid plan plus extra editors is still cheap compared with a design agency, but it is no longer the "one low monthly fee and we're done" narrative many affiliate posts imply. For a solo founder that may be irrelevant. For a six-person studio it matters.

3. Performance is a measurement problem, not a promise

Framer is much better than the old "pretty but bloated" caricature, but the only performance argument we trust is the page we measure ourselves. Our current hand-coded pages are straightforward. They are also predictable. Any migration would need a before/after check against actual page weight and mobile experience, not just a belief that a modern site builder will optimize everything for us.

4. We still like owning the code path

One under-discussed advantage of the boring static HTML route is certainty. When something breaks, we know where it lives. When we need a weird custom behavior, we do not negotiate with a canvas tool or a hidden abstraction layer. That matters less for brochureware and more for any page that slowly accumulates custom logic over time, which is what our marketing pages tend to do.

What would make us switch anyway

We would move a specific landing page to Framer if all of these were true:

• The page is primarily a marketing surface, not the beginning of a larger product/docs system.
• A designer needs to make frequent changes without waiting for developer time.
• The page is important enough to benefit from staging and collaborative edits, but not so infrastructurally weird that our own codebase is a better home.
• The total cost of plan + editors is still lower than the ongoing drag created by code-only ownership.

We would keep a page hand-coded if portability, exact output control, and low recurring cost beat design iteration speed. That is still the case for much of the vøiddo surface today.

The honest verdict

Framer is no longer an easy dismiss for us. If anything, the current platform is better than the old blogosphere consensus suggests. But the only honest conclusion from this weekend is narrower: Framer looks like a legitimate candidate for a future designer-owned landing page, not a blanket replacement for the hand-coded stack we already trust.

FAQ