What does it really take to build a flexible, fair, and scalable pricing model for a SaaS platform that serves everyone from indie devs to enterprise teams?
In this episode of Monetizing AI, Expo’s Joe (Head of Revenue) and John (Head of Product) join host Fynn Glover to break down how they approach monetization across wildly different customer types (and why great pricing isn’t science... it’s taste).
They dig into:
How Expo thinks about value-based pricing
The balance between predictability and flexibility
Usage-based vs. credit-based models
How entitlements and limits are handled
Why “pricing committees” kill momentum
And the underrated art of developing pricing taste
Whether you’re a founder, product leader, or revenue strategist, this conversation unpacks what modern monetization looks like in the age of AI-enabled SaaS.
Fynn Glover (host): Welcome back to Monetizing AI. Today I’m joined by Joe (Head of Revenue, Expo) and John (Head of Product, Expo). Joe suggested we make this a product–revenue conversation—which is perfect for talking monetization.
John: We have a wide surface area: cloud builds for iOS/Android, over-the-air (OTA) updates, and dashboards. We start by shipping valuable products, then work backward to pricing the value. The challenge: we can’t price everything the same way because value comes from different parts of the platform. So we search for what’s valuable to each customer segment and price that—pricing follows product and keeps evolving.
Joe: Our customer base is broad: indie devs “vibe-coding,” veteran developers, and enterprises. Monetization must provide clear on-ramps for each persona—sometimes they need one or two features, other times the full platform. We optimize for predictability and clear value, but those look different by segment.
Joe: It depends—always start with discovery. If someone just needs OTA because CodePush was deprecated, we talk MAUs and the growth path. If they’re all-in on Expo (builds, CI/CD, frequent releases), we cover predictability, scaling, and how usage ebbs and flows across sprints. Pricing lands better after we understand the outcome they’re chasing.
John: We basically price three things:
Team & insights (dashboards, organization of builds/submissions): subscription tiers ($20/month to ~$2,000+ for enterprise).
Cloud builds & CI/CD workflows: usage-based (minutes, runs) because iteration cadence varies.
OTA updates & hosting: tied to end-user scale and traffic.
Big challenge: making all of this make sense for PLG without end-of-month surprises. That’s where in-product education and transparent metering matter.
Joe: Exactly—some customers don’t even know what a CI pipeline is yet. We need to teach while we price.
Fynn: Your docs and pricing page make predictability a principle.
John: Customers tell us that constantly: “Please tell us what this will cost.”
Joe: We balance it by product and segment. For Workflows (charged by minutes) some want prepaid (credit drawdown), others need usage-in-arrears to learn their pattern first. Over time, once patterns are known, we can make usage more predictable with annual constructs.
Contract mechanics that help enterprises
Start usage-based to learn, then graduate to predictable commitments.
Smooth volatility across the year: if a high month is offset by a low month, don’t nickel-and-dime overages; design for averages.
Credits vs. usage: pick based on predictability needs; the meter (value exchange) comes first, payment mechanics second.
John: It depends. For unknown listeners: “We give you everything you need to build apps and get them to stores/users.” Think “bundle by default,” with room to swap pieces based on context.
Joe: For new builders: speed and simplicity. For enterprise: outcomes, packaging, and ACV that fits their goals and procurement motion.
John: We shrank the “pricing committee” to three people: me, Joe, and our CTO James. We model costs, define value, propose a plan, and decide. Fewer voices = less paralysis.
Operationally, we’re on Stripe plus internal tables; piping/deriving usage into invoices can be tricky and slow—so we’re building a simpler tracking system. The goal is to make iteration faster.
Joe: A recent example: we changed an old on-demand plan (pure usage, card on file) to $19/month. We weren’t 100% certain, but had conviction from comps and customer goals. Four weeks later: 2,000+ signups. The win gives us space to test upsells/add-ons next.
Fynn (definition): Entitlements = what a user/customer can do based on their commercial context (plan/contract), including limits and evolution over time.
John: We store, per user/account, both permissions and feature access. All usage flows through an internal “entities” middleware:
Check: do you have permission?
Bill: if billable, record against the right meters/tables. Events come from GitHub (build kicks), OTA events, etc. It’s centralized for gating and billing.
Joe (plan structure): We have Free, Starter, Production, Enterprise. Capabilities are similar; differences are priority (e.g., build queues), support level, and included usage thresholds. We’re adding enterprise-specific capabilities (analytics/observability at org scale) over time.
Joe: We designed a usage-based system up front—no hard caps on core meters. You can always keep building; you pay for what you use. That gives flexibility and avoids “your app blew up, so we turned you off.”
John: We still care about transparency. We’re improving early warnings and threshold signals so customers see spikes before an uncomfortable bill—without blocking growth moments.
Get the meter right first. The value exchange (minutes, MAUs, builds, etc.) matters more than whether you pay upfront or in arrears.
Predictability is a feature. Especially for enterprise budgeting. Use contracts and averaging to smooth volatility.
Shrink the room. Small decision group = faster iteration and less “pricing committee” stall.
Educate inside the product. Great onboarding + usage transparency prevents surprise bills.
Treat pricing as open-door decisions. Ship, observe, adjust. Iteration beats theory.
John: Pricing is only partly science. A lot of it is taste—intuition for what customers will accept and value. Move fast with conviction, then learn.
Joe: “Pricing taste” + “yes-and” energy. Try it, measure it, refine it.
Fynn: Love it. Thanks, both—this was super instructive.