Every engineering team building at scale eventually hits the same wall. It doesn't announce itself. You're moving fast, shipping features, closing enterprise deals, and then someone asks: "Can we add a new plan?" And the answer is more complicated than it should be.
That's where Miro's story begins. Susan, Growth Engineering Lead, shared it at Stripe Sessions this year alongside Dor, CEO of Stigg. The theater filled up fast. Then it kept filling. Engineers stood along the walls. People sat on the floor. A crowd gathered at the entrance that couldn't get in at all.
If you weren't in the room, here's what you missed.
The Hidden Cost of Organic Growth
Miro's monetization logic didn't start as a problem. It started as a sensible system that grew with the company. Plan checks scattered across the codebase. Hardcoded plan names like Company, Free, New_Free, and, memorably, Free_Team_2018. Enterprise contracts managed separately from self-serve. Entitlement logic embedded in application code and tied to billing systems.
No single bad decision created this. It was the accumulation of reasonable choices made under pressure, over years. The system worked until it didn't.
The wake-up call came when introducing a new plan surfaced just how deeply monetization assumptions were buried in the code. Making changes meant coordinating across many teams, with coordinated changes across the codebase, and engineers nervously on call. The team knew more complexity was coming, and they weren't ready for it.
When AI Made Everything Harder
Then Miro decided to launch Innovation Workspace, their AI-powered collaboration platform. The requirements escalated fast: AI credits that vary by plan, credit allocation calculated using seat count, monthly resets with automated tracking, hard enforcement for some contract types and soft enforcement for others, and real-time visibility for admins and sales teams. All of it needed to integrate cleanly with existing billing and backend infrastructure.
And the edge cases kept coming. Trial credits needed to be tracked separately from paid credits so usage data could inform post-trial recommendations. Beta AI features needed their own credit type with safe daily limits, completely isolated from production credit balances. The existing in-house entitlements service wasn't close to handling any of this.
Build vs. Buy, With an Honest Accounting
Miro had already invested three engineers over three months trying to solve the challenges around entitlements internally. The calculus was straightforward: continue down a path that was getting harder, or find something purpose-built for the problem.
When they evaluated Stigg, two things stood out. First, it covered requirements Miro had already identified. Second, it covered requirements they hadn't thought of yet. Org trials, user-level trials, promotional entitlements: capabilities that weren't on the roadmap but became immediately useful once available. The decision wasn't difficult.
One Layer, Not a Replacement
The architectural change is worth understanding precisely. Miro didn't replace their billing provider, their CRM, their analytics, or their finance systems. They added one layer, a single source of truth for entitlement decisions, that informed all of those systems.
All monetization logic now lives in one place. Entitlements, credits, metering, enforcement, and plan management: consolidated rather than distributed. The client application went from encoding monetization knowledge to asking a single question: Can this user do X? Yes or no. The complexity moved out of the application layer entirely.
The Enforcement Model That Actually Works at Scale
There's an important distinction that gets blurry when teams build entitlement logic on top of billing infrastructure. Billing answers "what happened?" Enforcement has to answer a completely different question: "what's allowed to happen right now?"
These operate on fundamentally different time horizons. Billing can reconcile after the fact. Enforcement has to be right in milliseconds, before anything executes.
What Miro shipped was a layered decision path evaluated atomically on every request. Plan entitlements determine whether the user has access to the feature at all. Credit balance determines whether they have enough to proceed. Rate limits check whether they're within their per-user threshold. Enterprise allocations verify whether their team has budget remaining. Every layer evaluated in sequence, one answer out the other side: allowed or blocked. Deterministic, auditable, and consistent across concurrent requests. No distributed disagreement about whether a request is valid. No discovering at month-end that something should have been stopped three weeks ago.
What Shipped, and How Fast
Miro adopted Stigg for entitlements, and then were able to deliver in 6 weeks a fully functioning hybrid seat-and-usage-based AI model in production. AI credit allocation calculated from seat count. Separate credit pools for trials, production, and beta features. Monthly tracking, enforcement, and automated resets. Real-time admin visibility across the board.
Yuliya, Miro's Head of Growth, put the timeline in perspective: "Three months before launch, we didn't even have AI credits as a concept. Six weeks after, we had the whole thing live."
The longer-term numbers are more telling. Miro estimates 5,000 engineering hours saved by not building and maintaining this infrastructure themselves. Pricing and packaging changes now move six times faster. A recent four-month window delivered a new plan, a new add-on, user-level feature trials, and a reworked AI credit allocation model. Four changes that previously might have each taken six months individually, shipped together.
The Hundredth Change
Perhaps the most underrated part of this story is what happens after launch.
In the old model, grandfathering a product for existing users and introducing a new version was a full project: find all references to the feature, coordinate across teams, plan a coordinated rollout, have someone on call. Engineering time, organizational friction, risk.
With Stigg, Miro did it with a configuration change. Millions of users. No disruption to existing flows.
The velocity shift isn't just about shipping faster the first time. It's about what the hundredth change looks like. That's where the compounding impact shows up, when the team stops dreading monetization changes and starts treating them as routine configuration.
If any of this resonated, Stigg has a free tier where you can model your own plans, credits, and entitlements and get a feel for how the pieces fit together. No commitment, just a good way to see whether the abstraction matches how you're thinking about your own system.
And if you're in the middle of this problem right now and want to think it through with someone who's seen a lot of these architectures, reach out. Bring the messy parts, we can handle it.
