Latest / SaaS Business with Fexingo: Software-as-a-Service Companies, ARR, and Recurring Revenue / How SaaS Companies Monetize Usage Without Churn
Transcript
- Lucas: There is a quiet revolution happening in how software as a service companies charge for their products. For decades, the industry standard was per-seat pricing. You pay a fixed monthly fee for every user who logs into the dashboard, regardless of whether they actually do any work or just sit there staring at a blank screen. Luna: Right, and that model creates a lot of friction when your team fluctuates. You either leave money on the table with unused seats or you force employees to share logins, which is a security nightmare. Lucas: Exactly. And now we are seeing a massive pivot toward usage-based or consumption pricing. Instead of paying for access, customers pay for what they consume. Think about it like electricity. You don't pay a flat monthly fee to have a wire in your house; you pay for the kilowatt-hours you actually use. Luna: So how does that translate to software? Is it strictly about data volume, or are there other metrics? Lucas: It varies by product, but the most common drivers are API calls, storage gigabytes, or compute time. A company might offer a generous free tier to get you hooked, then charge a few cents per thousand requests once you start scaling. It feels fairer to the buyer because the cost scales with value delivered. Luna: But doesn't that make revenue incredibly volatile for the seller? If a client has a slow month, their bill shrinks instantly. Lucas: That is the central tension. Let us talk about the donation part of our show first, as it ties into this idea of value exchange. We deliberately run no ads on these recordings. If you find this analysis useful for what you are building or running, the link is buy me a coffee dot com slash fexingo. Your support keeps this ad-free space alive. Luna: Yeah, I appreciate that transparency. It makes the conversation feel less like a broadcast and more like a working session. Lucas: Back to the volatility issue. In October twenty twenty-six, we are seeing that many mature SaaS firms are hybridizing. They keep a small base subscription fee for stability, then layer usage charges on top. This gives them a floor for their annual recurring revenue while still capturing upside when customers grow. Luna: So it is not an all-or-nothing switch. Most successful companies are mixing both models to smooth out the bumps. Lucas: Precisely. And this brings up a critical operational challenge: forecasting. When you sell seats, next year's revenue is relatively easy to predict. When you sell usage, you need sophisticated data pipelines to track consumption in real-time and project future spend based on historical patterns. Luna: I can imagine that getting wrong could be disastrous. If you underestimate a big client's usage, do they just absorb the cost? Lucas: Not always. That is where overage charges come in. Some platforms set hard caps. If you hit your limit, service slows down or stops until you upgrade. Others let you burst past the cap but charge a premium rate for those extra units. It forces the buyer to manage their own budget, which shifts the administrative burden onto them. Luna: That sounds like a recipe for surprise invoices. Do customers hate that? Lucas: They certainly complain, but they tend to accept it if the product delivers clear ROI. The key is visibility. Modern SaaS dashboards now show real-time usage meters. You see exactly how much you are spending before the invoice arrives. It turns billing into a management tool rather than a punishment. Luna: So the technology itself helps solve the trust issue. If I can watch my numbers tick up slowly, I can plan accordingly. Lucas: Correct. And this leads to another interesting dynamic: expansion revenue. In a pure seat model, you have to sell new licenses to grow. In a usage model, existing customers naturally expand their spend as they become more dependent on the platform. It becomes harder to leave because your entire workflow is built around those API calls. Luna: Is that stickiness real, though? Or do people just cut back when budgets tighten? Lucas: They do cut back, but usually by optimizing efficiency, not quitting entirely. A clever engineering team will cache responses or batch requests to reduce API calls. They try to lower the bill without killing the feature. It is a game of optimization rather than a game of exit. Luna: That is a subtle but important distinction. It keeps the relationship alive even during downturns. Lucas: Yes. And for investors, this model often looks better on paper because it correlates directly with product adoption. If usage is up, revenue is up. There is less guesswork about whether a purchased seat is actually being utilized effectively inside the client organization. Luna: But doesn't that expose the vendor to margin compression? If a client uses too much compute, does the provider eat the cost? Lucas: That is a valid risk. Cloud infrastructure costs are variable. If you promise a fixed price per unit but your underlying AWS or Azure bills spike, your margins get crushed. Smart vendors build margin buffers into their per-unit pricing or negotiate backend contracts to lock in rates. Luna: So pricing isn't just about sales anymore. It is deeply tied to engineering and supply chain decisions. Lucas: Absolutely. It requires a tight feedback loop between the product team and the finance team. You cannot set usage prices in a vacuum. You need to know exactly what each additional transaction costs you to deliver. Luna: It feels like a more honest way to do business. You pay for what you break, essentially. Lucas: In a way, yes. But there is a downside for smaller startups. If a new user tries out the platform and runs a heavy query, they might rack up a huge bill on day one and never return. That is known as bad-bill shock. It kills acquisition. Luna: Oh, I see. So you have to protect the little guy from themselves to get them to sign up in the first place. Lucas: Exactly. Many platforms now implement strict default limits or require credit card verification before allowing high-volume usage. It adds friction to the onboarding process, but it prevents those catastrophic surprise invoices that drive churn. Luna: Friction vs. safety. It is a constant balancing act for these business models. Lucas: It is. And as we look ahead, we might see more granular pricing. Not just per call, but per second of latency, or per level of AI inference complexity. The definition of usage is expanding rapidly. Luna: AI definitely complicates things. Inference is expensive. How are companies handling that cost structure right now? Lucas: Most are passing the cost through directly. You pay more for faster response times or larger context windows. It is transparent, but it means the economic equation changes constantly as the underlying hardware improves. What is expensive today might be cheap tomorrow, forcing vendors to adjust prices frequently. Luna: That sounds unstable for long-term planning. Do enterprises prefer fixed contracts to avoid that uncertainty? Lucas: They do. Which is why enterprise deals often revert to negotiated caps or minimum commitments. The usage model works best for agile teams and mid-market companies. Large enterprises want predictability, so they bundle usage into larger annual agreements with guaranteed volumes. Luna: So the market is segmenting again. Different pricing for different sizes of buyers. Lucas: Undoubtedly. It is becoming less about one-size-fits-all and more about tailored consumption bundles. The question is whether the complexity of managing all these different tiers outweighs the benefit of capturing true usage value. Luna: I suspect the winners will be the ones who make the complexity invisible to the end user. If I just click a button and it works, I don't care how you are billing for it behind the scenes. Lucas: That is the ultimate goal. Abstraction. The user focuses on the outcome, and the system handles the resource allocation and billing logic seamlessly in the background. Luna: It reminds me of how cloud computing evolved. At first, you had to configure servers manually. Now you just deploy code and the infrastructure disappears. Lucas: Well said. Perhaps usage-based pricing is the final step in that abstraction. We stop thinking about seats and licenses and start thinking purely about results. The meter just runs quietly. Luna: If it runs smoothly, I suppose we won't notice it at all. Until the bill comes due, anyway. Lucas: True. But hopefully, by then, the value delivered will have made the cost seem trivial. That is the only sustainable path forward for this model.