Why We Build in Webflow — and When We Don't

The case for Webflow as a primary platform, honestly made. What it gets right, where other platforms still fit, and how fifteen years of building in Drupal shaped the way we think about CMS architecture.

Published on
March 7, 2019

There's a version of this post I could write that reads like a platform announcement. Webflow is excellent, here's why, end of post.

That's not the version that's actually useful.

The more honest version starts with where we came from. Before Webflow, MacPhee Design was a Drupal studio. Not in a passing way — I co-founded Design 4 Drupal, Boston at MIT. Drupal's content architecture, its modularity, the way it forces you to think about content as structured data before you think about how it looks — that shaped how I approach every project, still.

So when I tell you Webflow is the right platform for most of the organizations I work with, that's not a platform preference. It's a conclusion I arrived at through fifteen years of building in systems that required considerably more from everyone involved.

What Webflow Gets Right

The problem Webflow solved for me wasn't a WordPress problem. It solved the handoff problem. As a designer working in Drupal, I was building in Sketch or Photoshop, handing comps to a developer, and hoping the translation held. It usually didn't, not completely. Design intent shifts in handoffs. Fixing it means another round of back-and-forth.

Webflow puts design and development in the same environment. What I build in the canvas is what gets built. The code it generates is clean, semantic, and fast — not the bloated output of a page builder trying to approximate design intent, but actual HTML and CSS that reflects the structure of the design.

For content-driven organizations, the CMS architecture matters as much as the design. Webflow's Collections work the way Drupal's Content Types work: you define what a thing is before you decide how it looks. A Staff member is a Staff member — not a blog post with a headshot awkwardly attached. That distinction sounds small until you need to surface, filter, or relate content across a site, and then it's everything.

The maintenance picture is also genuinely different. Webflow manages hosting, infrastructure, and platform updates automatically. There are no plugin dependencies to monitor, no security patches to test in staging, no PHP compatibility issues to inherit after an update. For organizations without a dedicated technical team, this is not a minor convenience. It's the difference between a site that gets tended and a site that quietly accumulates risk.

Where Other Platforms Still Fit

Webflow isn't the right answer for every project, and I'd rather say that plainly than pretend otherwise.

For organizations that want a polished, professional site without custom CMS planning — a portfolio, a small service business, an event-based organization with straightforward content — Squarespace is a genuinely strong option. MacPhee Design is a Squarespace Professional Partner, and for the right project it's the right tool.

For large-scale enterprise sites that require Drupal's advanced permissions, complex multi-site architectures, or deep government or research integrations — the kind of project where the content governance requirements are as complex as the content itself — Drupal is still where that work gets done well. We know that world, and we're not pretending it doesn't exist.

The platform choice follows the project requirements. That's the whole of it.

What We Build On

For the majority of what MacPhee Design builds — custom, content-rich sites for nonprofits, arts organizations, healthcare, education, and professional services teams that need to own and manage their sites after launch — Webflow is where we do our best work.

If you're thinking about a platform change, or want a second opinion on what's right for your project, let's talk.