Before branded by existed, Evan and I were both marketing directors at the same company, a residential concrete business with more than 30 locations, over 100 employees not counting subcontractors, and millions of dollars a month in revenue. We'd just brought website work in house after years with an outside agency, and someone had to decide what to build it on.
I came from an agency background that was one hundred percent WordPress. That's what I knew. Evan had dabbled in WordPress too, but he was the one who said there's this new tool called Webflow, we should look at it. Another director on the team, who owned the website day to day, wanted to stay on WordPress. It turned into a real debate, and I ended up in the middle of it, trying to get everyone to agree on a direction.
A colleague named Adam is the one who finally convinced us Webflow was the future.
The debate wasn't philosophical. It came down to what our team was dealing with every week on the WordPress site: a plugin update breaking a page layout, a developer needed for changes that should've taken five minutes, and a growing list of security patches to stay on top of across dozens of location pages. That's not a knock on WordPress in general, it's a "WordPress at this scale, run by a lean internal team" problem.
Webflow removed most of that overhead. No plugin dependency chain to babysit. A visual editor where design and development live in the same place, so what you see while building is what ships. Hosting, SSL, and CDN handled by Webflow itself instead of something we had to piece together and maintain. And a CMS a non-developer on the team could actually open and edit without breaking anything.
None of that makes Webflow objectively better for every business. It made it better for a team that needed to move fast without a full-time developer on call, which described us then and describes most of our clients now.
Not long after, Evan and I left to start branded by full time, and we went Webflow first from day one. We've stuck with it ever since, including a trip to a Webflow conference in New York City a couple years ago where we picked up ideas we're still using on client sites today, from how we structure CMS collections to how we handle interactions and animations without bloating page load times.
We didn't choose Webflow because it was trendy. We chose it because we watched a genuine debate play out inside a real company and picked the side that held up, and every year since has given us more reasons to stay: faster builds for clients, a CMS their own teams can manage without calling us for every text change, and a platform that keeps up as a client's business grows instead of accumulating plugin debt.
This isn't a preference we hold onto out of habit, it's what we build nearly every client site on, across very different kinds of businesses. A home services company like Pitch Perfect Seamless Gutters. A 30-plus-year, multi-location retailer like Hot Springs Pools & Spas. A growing manufacturer like NovoBlend. A homebuilder like Hulbert Homes. A publicly traded biosciences company like PURE Bioscience. Same platform, same reasons, whether the client is a two-truck local business or a company answering to shareholders.
We made the switch after watching a real internal debate play out at a 30+ location company where we both worked before starting branded by. Webflow won on its own merits, faster builds, fewer plugin dependencies, and a visual editor that keeps design and development tightly connected, not because it was the newer option.
Our default is Webflow for the reasons above, but the right platform depends on a client's existing systems and technical needs. We'll talk through the tradeoffs on a discovery call.
Yes. It's a common starting point for new clients moving off an aging WordPress build.
Everything from local home service companies to growing manufacturers to publicly traded biosciences companies. The platform scales with a business without forcing a different tech stack at each stage of growth.
If you're deciding on a platform for your next site, what's actually driving that decision: familiarity, or what the site needs to do?
