"Billing" is productized; Monetization is the Challenge.

Billing has become one of the commoditized parts of SaaS. 

You can choose from a half-dozen commoditized solutions. Each will give you out-of-the-box solutions for invoicing, card charges, receipts, proration, refunds, taxes, dunning.

If you attempt to build billing from scratch, internally, then most people (rightly so) will call you insane. The abstraction exists at a trivial cost compared to maintaining a team of engineers to do it yourself. If there is any complexity in billing, it comes from navigating the financial aspect rather than the product aspect.

Within the modern billing stack, billing is now an out-of-the-box experience - monetization is definitely not. 

Monetization is so deeply embedded in your product that you can't separate it from core functionality. Every feature gate, usage limit, and pricing tier lives within your code and needs to be built, owned, and scaled by your product teams like everything else.

Let’s make a simple core distinction:

• Billing = the mechanics of collecting money (payments, invoices, taxes)
• Monetization = the strategic approach to packaging, pricing, and feature entitlements

Billing: basic and owned by finance

Billing platforms have matured over the past decade to support most SaaS needs. For example, Stripe Billing can handle recurring subscriptions, usage-based billing, invoice generation, and even revenue recognition reporting. These platforms invest heavily in compliance (PCI for credit cards, strong customer authentication, global tax law updates), so you don’t have to. Unless your business model is highly unusual, using a provider is usually a no-brainer. Most companies should happily pay Stripe its ~3% for the luxury of never having to manually create an invoice again.

For finance and revenue operations teams, billing has become essentially frictionless. They can configure pricing tiers, set up subscription plans, apply discounts, manage payment methods, and generate financial reports—all through dashboards. However, this apparent simplicity masks the significant upfront engineering investment required to integrate these systems properly. While basic operations like processing a refund or applying a custom discount can now be handled directly by revenue teams, more complex changes still require engineering support, and the initial integration is far from trivial. 

What does this mean for RevOps? They can focus on strategy and analysis rather than the mechanics of moving money. Even complex needs like revenue recognition, compliance, or dunning have been automated by these platforms. The problems that keep finance leaders awake at night are rarely about the billing system itself.

Monetization: extra and owned by product

The same is not true for monetization. And while monetization may seem like it should be keeping the finance team awake at night, they should not be the owners of monetization—this falls to product and engineering.

Let’s expand on that. Why does something with (almost) money in its name not fall into the purview of finance?

Monetization is strategic

This is why product managers own monetization. Monetization is the strategy and structure of the product being sold. This might include any or all of the following:

• Pricing models (subscription vs. usage-based vs. hybrid)
• Tiered feature access (what features belong in which pricing tier)
• Usage limits and metering (how to measure and cap usage)
• Free tier strategy (what to offer for free to drive adoption)
• Upgrade paths (how users progress through pricing tiers)
• Add-on and extension pricing (what's included vs. what's extra)
• Enterprise customization options
• Trial periods and conversion strategies
• Discounting strategies and promotional offers
• Value metrics (what usage or outcomes to charge for)

This genuinely isn’t even the half of it. Upsells, bundles, value metrics, customer segments—all of this is monetization and all of it is deeply entwined with the product. These decisions require deep product knowledge and affect the core user experience, which is why they typically belong to product teams rather than finance departments, even though they directly impact revenue.

Monetization is engineering

Monetization decisions map directly to application code, requiring significant engineering involvement. Consider these examples:

1. Usage limits require tracking and enforcement systems within the product
2. Feature access gates must be embedded in the authorization layers
3. Trial periods need logic for expiration and conversion handling
4. Tiered access demands complex permission structures
5. Usage-based pricing requires reliable metering infrastructure
6. Free tiers need technological guardrails to prevent abuse
7. Upgrade paths must trigger the right product experiences

When a monetization strategy changes, it rarely means simply updating a price in the billing system. Instead, it often requires rebuilding core parts of the product itself. Engineering teams must ensure customers get exactly what they paid for—no more and no less. This tight coupling between business strategy and technical implementation is why monetization requires close collaboration between product managers and engineers.

Let's say the monetization decision is to move to a freemium model to increase conversion. This isn’t a toggle-a-toggle in Stripe thing—someone has to build the logic to implement this strategy across your entire application stack.

From an engineering standpoint, implementing a freemium model requires several key components:

1. Feature gating mechanics: You need a robust way to control access to specific features based on a user's subscription status.
2. Usage tracking: You need to count and enforce limits for metered features (like API calls or storage).
3. Entitlements service: A system of record that knows what each user is allowed to access and to what extentUpgrade pathways: In-app prompts when users hit limits or try to access premium features.
4. Downgrade handling: Logic for what happens when a paid user cancels their subscription.

The challenge is that this cuts across your entire codebase. Each feature must be checked with your entitlements service before execution: "Can this customer  interact with this  feature ?" This becomes a significant engineering undertaking for companies with dozens or hundreds of features.

With Stigg, you would:

1. Create plans in the dashboard: Set up your free plan and paid tiers without writing code.
2. Define feature entitlements: Assign specific usage limits and feature access for each plan.
3. Integrate the SDK: Add code like this to your application:

// Check if a user can access a premium feature
const entitlement = await stiggClient.getBooleanEntitlement({
  customerId: 'customer-123',
  featureId: 'premium-analytics'
});

if (entitlement.hasAccess) {
  // Show premium analytics
} else {
  // Show upgrade prompt
}

Then you could track feature usage to report when customers use metered features:

// When a user makes an API call
await stiggClient.reportUsage({
  customerId: 'customer-123',
  featureId: 'api-calls',
  value: 1
});

Finally, you would configure the customer journey and set up automatic downgrades to the free plan when subscriptions end.

Unlike billing, monetization logic traditionally lives deeply embedded within your codebase. Without a proper monetization system, even small pricing changes become risky and complex—requiring modifications to authentication systems, database schemas, and user interfaces—all while maintaining backward compatibility for existing customers.

This is why finance teams can't effectively own monetization strategy—they lack both the product vision to determine what should be monetized and the technical understanding to implement those decisions. A MonetizationOS like Stigg provides the external APIs needed to control customer journeys, making these changes manageable and keeping monetization where it belongs: as a product problem, not a financial one.

Monetization challenges emerge at scale

Monetization isn't a singular, fixed concept with one "right" implementation. As the user base grows and a company expands its market, monetization becomes a “scale problem” and an engineering concern.

For instance, over time, you will iterate on pricing. That means multiple generations of plans need to be supported in parallel—you can’t force existing customers onto the new pricing overnight if you’ve promised them a specific plan. Maintaining old plan versions alongside new ones complicates the entitlement logic. A plan name might stay the same but include different entitlements for customers who signed up earlier vs. later. Engineering needs to build versioning into the product catalog and ensure no customer loses what they paid for. This can involve tagging users with a plan version or date and conditional logic everywhere entitlements are checked. At scale, manual handling of this becomes error-prone without a systematic approach.

Or you grow, and as you enter global markets you may want to offer regional pricing. For example, $50/month might be standard in the US but too high in India or Brazil. Supporting multi-currency pricing adds complexity: the system might need to present different prices or packaging in different regions. Backend systems must handle currency conversion and localization of tax, while frontend needs to display the right currency and enforce any regional restrictions. Many SaaS companies encounter price localization problems when users suggest more optimized pricing for EMEA or Asian regions—something they can't easily support with rigid monetization infrastructure. It's only after implementing the right platform that product teams can quickly roll out and test regional pricing experiments.

The complexity doesn’t grow linearly; it explodes. Look back at the list of monetization strategies above and think about how they might change as a company grows:

• For startups, monetization often begins with a simple model—perhaps a single paid tier or basic freemium offering. The focus is on proving product-market fit and acquiring initial customers. Engineering teams implement basic feature gates and possibly usage tracking, but the systems are straightforward and manageable with minimal overhead.
• For growing companies, as the customer base diversifies, monetization needs to expand. Companies introduce multiple pricing tiers, annual billing options, and more granular feature differentiation. Engineering now needs to handle changing customer plans and various upgrade paths. The initial solution  becomes insufficient as more complex user journeys emerge.
• For enterprises, monetization becomes highly strategic with custom contracts, complex volume-based discounting, multi-year agreements, and sophisticated seat-based management. The technical implementation requires handling intricate billing scenarios, custom SLAs, and organization-wide entitlements across teams and departments. M&As compound this complexity, forcing teams to manage multiple inherited systems that create SKU sprawl beyond ugly. Each new enterprise contract might bring unique requirements that need to be accommodated within the monetization framework—all while maintaining backward compatibility for existing customers.

‍

‍

Each stage doesn't replace the previous one—it builds upon it. An enterprise-grade monetization system still needs to handle the basics a startup requires but with exponentially more edge cases, configurations, and integration points. 
At scale, optimizing monetization becomes an ongoing process. Pricing is not set-and-forget; the most successful companies run experiments and tweak continuously to find what maximizes revenue and customer satisfaction. For instance, Wix’s monetization team was able to run “30-40 A/B tests in a year, most of them on our pricing” once they had a proper platform. But doing that at scale requires infrastructure that allows for safe experimentation: serving different prices or packages to different user cohorts, measuring results, and rolling changes out (or back) without disrupting existing users. Without an architecture designed for it, A/B testing pricing can be perilous (you don’t want customers tweeting angrily about seeing different prices).

The ability to iterate quickly on pricing is a hallmark of product-led growth at scale, and it demands a flexible system. Feature flagging can be extended to pricing experiments, e.g., to show a new pricing page to 10% of visitors, but that requires entitlements and billing to handle conditional differences.

All these challenges illustrate that monetization is fundamentally an engineering scale problem. What works in a scrappy MVP can crumble when you have millions of users, multiple product lines, and constantly evolving business strategies. Companies that reach this stage often find that rigid monetization systems hold back their growth—as Webflow experienced when an inflexible architecture stymied new pricing ideas like usage-based plans.

Conversely, those who invest in a robust monetization architecture gain a competitive edge: they can roll out new pricing models or market experiments in days instead of months, respond to customer and market feedback faster, and capture opportunities (like regional optimization, tailored bundles, or premium upsells) that others might miss.

From Subscription to Usage to Success

As companies scale, they will always encounter new monetization challenges–internationalization, bundling, pricing models. That is why there is no true answer to monetization: there is only the next challenge.

The same goes at an industrial scale. In his interview with Unusual Ventures, Dor said:

We moved from perpetual licensing into the cloud and that allowed essentially the subscription economy [...] And now we're moving from subscription economy into [...] a usage-based economy with companies like Snowflake and Datadog and others doubling down in consumption, but now we're moving to almost of a success-based or work-based or outcome-based economy where born in AI type of products, whether they are generative assist or agentic, are being measured against success, almost like a service.

This is the next challenge to be added to that list of monetization strategies. How do you measure success? How do you measure outcomes? What’s the feature flag for that? This is how we’re thinking about monetization at Stigg to ensure our customers have the best opportunity to monetize their products effectively, whether for human or machine.

In essence, scaling a SaaS business goes hand-in-hand with scaling the monetization infrastructure. The challenge isn't just implementing your current monetization strategy; it's building a system flexible enough to evolve as your business grows, and as SaaS grows, from simple subscriptions to usage-based models to success-based partnerships—constantly demanding that engineering teams reimagine what monetization means.