Custom code, Framer, Webflow or WordPress: which one for your SaaS site?

Most comparisons of website builders are written by agencies that build on one of them, so the answer is always that one. We build client sites with custom code, Framer, Webflow and WordPress, and pick per project. Here’s how we decide.

The short version

• 01Framer. Best when a small team edits pages often. Tradeoff: less structure for large content sites.
• 02Webflow. Best when a marketing team needs a real CMS and structure. Tradeoff: steeper to learn; plan-based pricing.
• 03WordPress. Best when you need specific plugins or already run it. Tradeoff: plugin and update maintenance.
• 04Custom code (e.g. Next.js). Best when the site shares components with the product, or needs full control. Tradeoff: edits go through developers or a headless CMS.

None of those lines are about how the site looks. All four can produce a good-looking, fast site. The differences show up after launch, when someone needs to change something.

Choose by team

• 01Founders editing it themselves: Framer.
• 02A marketing hire who publishes weekly: Webflow, or a custom site with a headless CMS.
• 03Engineers who like pull requests, or AI coding tools: custom code.

The real question isn’t who builds the site. It’s who changes it in month six. A site that only an engineer can edit slowly goes stale when the marketer wants to publish every week. A site in a visual builder frustrates an engineering team that wants code review, version history and components shared with the app.

AI coding tools have changed the last line. A custom site used to mean every copy change waited for a developer. With a coding assistant working in the repository, someone who isn’t an engineer can describe a change and review it as a pull request. It isn’t right for every team, but it’s a real option now. This site, formform.co, is custom code (Vite and React, prerendered to static HTML), built with Claude.

Choose by budget

Compare the build cost plus running costs (plans, hosting, plugins, maintenance), and how much each change will cost you later.

• 01Build: design and development, once.
• 02Running costs: platform plans, hosting, paid plugins or integrations, and a CMS if the site needs one.
• 03Maintenance: updates, security patches and the occasional fix after a plugin or platform change.
• 04Each change: who makes it and how long it takes. A team that edits weekly pays this cost far more often than the build cost.

We don’t quote platform prices here because they change often. Check each vendor’s current pricing page and price your real usage: number of editors, CMS items, languages and traffic. For reference, our websites start at US$10k, designed and built, on whichever of the four fits.

Choose by editing needs

Blog or changelog? Many landing pages? Localisation? List these first, then check which stack handles them without workarounds.

• 01A blog, changelog or resource library that grows every week: a stack with a strong CMS, so Webflow, WordPress or a custom site with a headless CMS.
• 02Many campaign or landing pages built by marketers: Framer or Webflow, where new pages can be made from existing sections without a developer.
• 03An integration that already exists as a well-maintained plugin, such as memberships or a specific form tool: WordPress is often the shortest path.
• 04Pages that reuse product components, show live data from the app, or need to match the product exactly: custom code.

Pick the stack for whoever edits the site in month six, not for whoever builds it.

Does the stack matter for SEO and AI search?

Less than people think. Any of the four can rank well if pages are fast, render on the server and have clean metadata. What matters is that the content is in the HTML on first load, so crawlers and AI assistants can read it without running scripts. You can check by viewing the page source. More on writing for assistants in How to make your work legible to AI.

When to switch

When editing is the bottleneck, or the site has to share design with the product. Plan redirects so you keep search traffic.

Switching has a cost: a rebuild, a content migration and a map from every old URL to its new one. Don’t move because a new tool is popular. Move when the current one costs you more every month, in hours and missed pages, than the move would cost once.

A quick way to decide

• 01Write down who will edit the site and how often.
• 02List the content types: pages, posts, changelog, docs, languages.
• 03Note anything the site must share with the product: components, data, login.
• 04Price the build, a year of running costs and a typical month of changes.
• 05Pick the stack that handles all of it without workarounds. If two tie, pick the one your team already knows.

If you’re choosing a stack for a new or redesigned site, send your brief.

• Design
• Process
• Systems