Webflow, Framer
or custom code

The short answer: Framer if the site is a few pages and one person edits it, Webflow if content is the job and a team edits it, custom when the site has to do something specific or outlive the tool. Everything below is why that is more complicated than it sounds.

Our bias, stated up front

We build custom sites. That is what we sell, so read the rest knowing it. We have also talked clients out of hiring us, and there is a section below on exactly when we do that — it is the useful part of this article.

What each one actually is

Framer started as a prototyping tool and grew into a site builder. It is the fastest way from a design idea to something published. Strong at motion and layout, lighter on structured content.

Webflow is a visual front-end builder with a real CMS behind it. More to learn, more to configure, and considerably more capable once a site has categories, authors, filters and a few hundred entries.

Custom is not one thing. It ranges from a static site generator to a full application. The defining trait is not "hand-written HTML" — it is that nobody else decides what the site can do.

What it costs, September 2026

Two things people miss. First, the seat cost: Framer has charged per editor since May 2026, so a marketing team of four is not the sticker price. Second, the subscription never ends — a €30/month plan is €1,800 over five years, before anyone touches the design.

The five questions that actually decide it

1. Who edits the site after launch?

This decides more than anything else on this page. If one founder updates a page a month, Framer is pleasant and cheap. If a marketing team publishes weekly with categories, authors and translations, that is a CMS job and Webflow earns its extra complexity. If the people editing are developers anyway, the argument for a visual builder weakens a lot.

2. Does the Barrierefreiheitsgesetz apply to you?

If you are above 10 employees or €2 million and you sell, book or take appointments online, the law applies and the standard is WCAG 2.1 AA. No platform makes you compliant and none prevents you from failing. Webflow and Framer both output reasonable markup; both let you ship unlabelled icon buttons, illegible contrast and broken focus order without complaint.

Where it differs is repair. When an audit finds a problem in a custom build, you change the component. On a hosted builder you are limited to what the editor exposes, and some fixes end up as injected custom code — which is allowed, and also exactly the kind of thing that breaks on the next platform update.

We measured this market: nine in ten Austrian sites we tested fail, across every platform. The tool is not the variable. Whoever builds it is.

3. Where does the data have to live?

For an Austrian company this is a real question, not a theoretical one. Webflow stores customer and end-user data in the United States and relies on the EU–US Data Privacy Framework plus standard contractual clauses; EU-region hosting (Frankfurt or Ireland) may be available depending on plan. Framer provides a data processing addendum under Art. 28(3) GDPR.

Both are workable. But neither makes you compliant — you are the controller, they are processors, and your obligations do not transfer. If your sector or your legal department requires data to stay in the EU, verify the specifics in writing before you build, not after.

4. Can you leave?

Ask this while you still like the tool. Framer has no native code export. Third-party exporters exist; treat them as a workaround, not a guarantee. Webflow exports HTML, CSS, JS and assets on paid workspace plans — but the export excludes CMS content, ecommerce data, code components and localised pages. In other words, the part that took you two years to build is the part that does not come with you.

This is not an argument against either tool. It is an argument for knowing the exit cost on the day you sign up, because it only grows.

5. How unusual is what you need?

If your site is pages, a blog and a contact form, custom development is hard to justify — you would be paying us to rebuild something that already exists. The moment there is a configurator, a booking flow with real availability, an integration with the system that actually runs your business, or a performance requirement somebody measures, the visual builder starts costing more in workarounds than the thing would have cost built properly.

When we tell people not to hire us

Genuinely, this happens. We suggest a platform when:

• the site is under roughly ten pages and will stay that way
• nobody internally writes code, and nobody plans to
• speed to launch matters more than anything structural
• the budget is better spent on photography and copy than on engineering — which, for a small hospitality or retail brand, it very often is

A good site on Webflow beats a custom build that ran out of money at 70%. We have seen both.

Where custom actually wins

• The site has to do something. Not display things — do them.
• Performance is a requirement with a number on it. We got this site's critical path to 97 KB; that is not a builder-shaped outcome.
• Accessibility has to hold under audit, including the parts a scanner does not reach.
• The site outlives the tool. Ten-year horizons and per-seat subscriptions are an awkward pair.
• It has to integrate with the ERP, the booking engine or the thing your business actually runs on.

How we would decide in one minute

If you are between two of these, the honest move is a short technical review before anyone commits. That is how we start every project, and it ends with a written scope rather than an opinion.