Webflow Powers Fine-Grained Access for Enterprises with Oso

The Platform And Team Behind the Sites You Use Everyday 

Webflow is a Website Experience Platform (WXP) that empowers teams to visually build, manage, and optimize stunning websites that offer both the consumer experience customers expect and the enterprise-grade performance and scale they need. 

With a visual, composable CMS at its core, Webflow gives teams full control over their websites without reliance on engineering. Its AI-driven personalization enhances user experience and optimizes site performance, helping businesses drive higher conversion rates and measurable growth. Today, over 300,000 of the best companies in the world, and more than 1,500 Certified Webflow Partners, create best-in-class, high-performing sites with Webflow. Oso — the very site you are visiting today — is running on Webflow

Justin Helmer led the engineering efforts to revamp Webflow’s authorization system. As Senior Staff Engineer, Justin works on projects that touch every part of Webflow’s code base. This includes services that optimize and measure user experiences, real time services, and most recently, permissioning. Working alongside Justin is Staff Software Engineer Dan Goslen, who is taking over authorization using his previous experiences of building access controls for low-latency distributed web systems. 

All-or-Nothing Access Doesn’t Cut It In The Enterprise 

As Webflow moved deeper into the enterprise market, its homegrown authorization system hit hard limits. Originally designed to grant broad entitlements at the site or workspace level, it couldn’t support the fine-grained controls larger customers required. Enterprises wanted the ability to specify who could edit this CMS collection or that page. This demanded a level of control that Webflow’s JSON-based authorization model simply wasn’t built to handle.

The scaling issues compounded as Webflow grew:

• The JSON model became harder to evolve and manage once relationships numbered in the hundreds
• Access checks tied directly to the main application database began to impact performance. At peak load, authorization queries slowed down and competed with core application traffic for resources. That created real friction for both users and developers.

Just as costly was the developer experience. Adding or changing roles meant wrestling with complex policy code that didn’t map cleanly to Webflow’s own data structures. Mistakes were common, and they weren’t cheap. 

A team spent two weeks making a few small changes to authorization. In review, it got rejected entirely. That was two full weeks of engineering effort completely wasted. When you consider the time of all of those who reviewed and tested the code as well, it adds up to a lot of money. And it wasn’t an isolated incident.

- Justin Helmer, Senior Staff Engineer, Webflow

Any changes also created risk. With permissions cached in some parts of the system, updates weren’t reflected consistently across the platform. Engineers often had to burn hours in long Slack threads just to work out how the model behaved in specific cases. “It was really hard for developers to make changes without accidentally breaking stuff and elevating permissions,” Justin noted.

For a company pushing to serve enterprises at scale, these issues were unsustainable. Webflow needed a way to move beyond coarse-grained access, without sacrificing developer velocity or pulling critical resources away from building features for customers.

Solving the Hard Problems First

Moving upmarket meant fine-grained authorization was no longer optional. Customers needed control at the level of individual resources, not just broad roles. 

Beyond granularity, Webflow’s shift from a website builder to a full Website Experience Platform brought new classes of users such as marketers, operations staff, and other non-designers, each with distinct role and access and needs. Customers also demanded locale-based permissions, such as segmenting who could manage content for different regions. Company acquisitions added another challenge: each new tech stack carried its own approach to authorization, increasing fragmentation.

Developer experience was equally important. The team wanted to make it easier for engineers to reason about and maintain over time. As Dan Goslen says: “Anything we can do to reduce fragmentation and converge our model over time sets us up better to scale velocity in meeting new authorization needs from our customers.”

Justin stresses the importance of defining these requirements before considering whether to build or buy a potential solution. “The first goal was to deeply understand the customer need, what we had built, and what the gap was,” he explained. “Then ask: what are the hardest technical challenges, how have others solved them, and what patterns can we learn from? Only then can you decide on the best path forward.”

When weighing the decision to build versus buy, the team quickly saw that rolling their own solution would come at a steep price. Building and tuning a distributed authorization layer in-house would require major upfront engineering investment, plus years of ongoing maintenance that would pull developers away from shipping customer-facing features. 

The evaluation reframed the entire decision: solving authorization at scale wasn’t just about adding new capabilities, it was about avoiding years of distraction from Webflow’s core product roadmap.

- Justin Helmer, Senior Staff Engineer, Webflow

One Solution Checks All The Boxes

Webflow’s engineering team compared Oso to several Zanzibar-style products as options for its authorization platform. The decision centered on four criteria: architecture, performance and resilience, vendor support, and team enablement.

Architecture. Webflow needed more than a Zanzibar-centric authorization model that flattens all access rules into user–resource relationships. Oso’s policy-based approach, built on its declarative Polar language, provides them the flexibility to model RBAC, ABAC, and ReBAC authorization models in a single system. 

A key Oso feature is Resource Blocks, giving a way to define all the access rules for a specific object in the app, such as a document, repository, or organization, including its roles, permissions, and relationships. This provides Webflow engineers a concise, centralized way to manage permissions complexity and standardize authorization across teams.

Performance and resilience. All vendor products could scale horizontally, but Oso demonstrated stronger real-world results, with consistent sub-10ms latency across thousands of requests per second. The platform also demonstrated near-continuous uptime measured over multiple quarters. In addition, on-prem Fallback Nodes allow authorization to continue even if Oso Cloud becomes unreachable. As Justin says, “Reliability is non-negotiable. We need sub-10ms checks we could trust, no matter the load or outage scenario.”

Support. The Webflow team valued Oso’s comprehensive documentation, rapid Slack responses from senior engineers, and quick delivery of requested fixes and features. Justin remarked, “The depth of engineering knowledge really stood out. The Oso team is able to talk at different attitudes on authorization in general and deep into the technology”. 

Team Enablement. Oso’s tooling, including its CLI, IDE integrations, and CI/CD support, lowers the barrier for developers and standardizes how policies are written and deployed. As Dan said “We’ve already seen how representing new resources in Polar is intuitive for other engineers. Coupled with testing, it makes it easy to assert that changes to a policy are  correct”.

Before taking a final decision, Justin built a simplified Google Drive–style proof of concept, stress testing it across the different vendor offerings to evaluate developer ergonomics and scalability. That exercise exposed a clear gap: while some tools looked appealing in a demo, they struggled with complex, real-world scenarios and fell apart under enterprise-scale requirements.

Following our evaluations, Webflow selected Oso for its flexibility to support any authorization model, operational strength, hands-on support, and developer-focused experience.

- Justin Helmer, Senior Staff Engineer, Webflow

Future State: Authorization as a Utility

For Webflow, selecting Oso wasn’t just about fixing immediate gaps. It was about setting up a long-term foundation for scale. The team wanted a centralized system that could grow with the platform, unify policies across services and acquisitions, and keep pace as new enterprise requirements emerged.

Equally important was freeing engineers to focus on customer value rather than infrastructure. By moving business logic into Oso’s policy layer, Webflow eliminates duplicate code and avoids rewriting authorization rules for every new product or tech stack. Oso’s support for transitional architectures made this shift possible without the risk of a “big bang” migration, letting Webflow adopt incrementally and safely. As Dan says

“We plan to centralize all authorization data into Oso,.but doing so takes time. The transitional approach has allowed us to prove the Oso platform for both new and existing use cases without rewriting large parts of our system upfront.”

Ultimately, the outcome Webflow is aiming for is simple: stability and focus. 

Oso brings us peace of mind. Authorization should be a utility, like water or power. It should just work, so we can keep innovating for our users instead of rebuilding the wheel.

- Justin Helmer, Senior Staff Engineer, Webflow

Key Lessons for other Engineering Leaders

Justin and Dan shared the following key learnings:

• Understand the Oso data model and query API. Policies are intuitive to write, but relationships between resources differ from a typical relational model. Understanding this early, along with how queries read and write data, pays dividends in performance and developer productivity.
• Keep authorization out of business logic. Treat it as a separate layer, not something scattered across application code. This makes it easier to reason about, test, and evolve without introducing accidental privilege escalations.
• Think beyond the demo. Many solutions look simple at first but break down under real-world complexity and scale. Start with the hardest problems you’ll face—like fine-grained rules, performance at peak traffic, or cross-service consistency—and evaluate whether a solution can handle them.

Justin underscored the role of partnership in making the shift successful: 

Oso gives us the flexibility and maturity we need, but just as important, they’ve guided us to make the right choices along the way. That alignment sets us up to scale authorization with confidence.

What Comes Next

Webflow’s journey reflects the reality Oso sees with many high-growth software companies: homegrown authorization can work in the early days, but it eventually becomes a brake on enterprise adoption, developer velocity, and product evolution. By grounding the build-vs-buy decision in a clear understanding of customer needs and technical challenges, engineering teams  avoid years of distraction and land on a platform that meets both near-term requirements and long-term ambitions. 

Looking to take your own products upmarket, but struggling with where to get started? Our engineers are always available to share guidance on getting started with authorization design, scaling complex permission systems, or tackling specific challenges your team faces. Start the conversation by meeting an Oso engineer.