I speak from experience when I say PDE teams love spending time on meaningful feature work that drives the business forward. Virtually no one wants to spend their productive hours obsessing over the nuances of their product's billing system. I'm biased, of course. We specifically built Stage to help software companies solve the long-standing issues that come along with building and maintaining functional billing systems. You can read more about what we're doing here.
I've spent most of my career working with SaaS companies that consistently faced issues with their home-grown billing solutions. They were often inflexible, costly, and demanded attention from resource-constrained teams they simply did not have, lest they sacrifice meaningful product development cycles to maintain the system. Here, we'll dig deeper into why existing billing system solutions leave teams wanting and what we can do.
Before we get into the Why of what makes in-house billing systems painful, we should define our terms. For SaaS companies, a billing system is all of the things that go into understanding how much money your customers owe you (accounting), telling customers how much they need to pay you (invoicing), and collecting what is owed (payment processing). SaaS companies, like Stripe and Chargebee, specialize in automated invoicing and payment processing, so there is some coverage for companies looking to offload aspects of their billing system.
Accounting, however, involves several critical components. Firstly, it necessitates a well-thought-out pricing strategy, determining the appropriate amount to charge customers for using your product. Additionally, accurate accounting relies on configuring entitlements that align with your pricing strategy, enabling you to charge customers accordingly. "Entitlements" is a fancy way of saying, "These customers are entitled to usage of certain features when they subscribe to your product." To bridge your pricing strategy with entitlements for accounting, engineering teams create "billing logic." This logic ensures a seamless connection between what customers pay and the features they can access.
In 2020, I joined the team at Loom, which was on a mission to transform asynchronous communication. It was in the early days of the pandemic, so there was a pressing need in the market for products facilitating remote collaboration among teams. It wasn't long, however, before the entire PDE team updated our existing billing system to reflect an entirely new billing paradigm. Updates like these occurred not once but on four separate occasions over two years and proved to be difficult for several reasons:
Loom was at an exciting inflection point at the time. Historically, it had been a business-to-consumer (B2C) SaaS company where each subscriber was responsible for overseeing their subscription. Recognizing the growth potential, however, the company decided to pivot toward a B2B product offering where multiple users would be aggregated under a single billing record, allowing the company to take on more significant business opportunities.
It was an excellent strategic move, and the timing was perfect, so the work began. Leadership spent weeks crafting "Good, Better, Best" pricing and packaging. It included role-based access, usage limits, security authentications, and more. Implementation teams then spent months executing. Product, design, and front-end spent time creating the user experience of role promotions and demotions, upgrade and downgrade flows, and more. Meanwhile, engineering teams considered the billing logic and how to account for new pricing and packaging under this new billing paradigm.
It was like steering a freight ship when it should've been like racing a speedboat.
Amassing all of these resources for something so time-critical put the speed at which we could make it to market at risk. We spent months on something that, had we miss-timed the market or been late, we'd have missed out on significant revenue opportunities. We also took on reputational risk: if our product experience or the billing system broke and – as a result – broke a brand promise, it diminished our credibility. There was also the risk of sunk costs. We were essentially betting on the idea that teams, not just individuals, needed Loom if they were going to navigate the remote world successfully, but was that market there? And how quickly could we iterate if we were wrong, given how much time we've invested in this process already?
It would be another three iterations on pricing and packaging and another 18 months before we had it somewhat dialed in.
I'd be remiss if I didn't say that seismic changes like this don't happen often. Despite this, they leave a mountain of maintenance tasks in their wake. These include bugs to fix, edge cases to consider, and technical debt or fast-follows to be addressed. Customer feedback exposes the imperfections in our billing systems, which can sometimes prompt leadership teams to hyper-focus on solving these issues. This can, however, come at the expense of innovation and can be dangerous for the morale of any group.
Philosophically speaking, when we hear consistent feedback from our customers, acting on that feedback as quickly as possible is a good practice. However, changes to your billing system, depending on their scope, can require the attention of your entire PDE team if you're to keep the billing system and user experience in sync. Seemingly small changes like updating a user role's access rights or decreasing a usage limit carry more weight from an implementation perspective. This can delay how quickly we are capable of responding to customer needs and shifts in our market. Suppose these needs are left unfulfilled for too long, or we need to evolve our pricing strategy to align with shifting market demands. In that case, customers will opt for solutions that are more suitable to their immediate needs.
Openview partners recently published the second edition of their "The State of Usage-Based Pricing" in which they stated, "61% of SaaS companies say they either have usage-based pricing or are actively testing it." This pattern is based on a broader shift among SaaS companies toward product-led growth (PLG) and the idea that usage-based billing is inherently PLG "because customers pay as they use your product".
The shift in PLG companies toward hybrid pricing models, which consist of both subscription and usage-based pricing, suggests that those who can quickly adjust their pricing to reflect this new norm will be better off than those who don't. Given the effort involved in shifting billing paradigms and the ongoing maintenance cost, it is understandable how difficult adopting these models can be for resource-constrained SaaS companies. Failure to do so, however, potentially puts one's business at risk.
As teams deepen their familiarity with customer needs, they think of novel approaches to solving core customer problems. The best teams continually iterate on these solutions, unlocking additional product value and addressing the constantly shifting needs of customers. This dynamic is good for business, leading to satisfied customers and fulfilled teams. However, when your home-grown billing system inevitably accrues excessive maintenance costs, this dynamic shifts. PDE teams must now allocate precious cycles to addressing billing issues rather than addressing customer needs. Internal teams are disconnected from the customer, affecting their ability to proactively anticipate and address user needs. As you can imagine, this results in frustrated customers who feel their needs are not being met and unfulfilled teams who believe they aren't helping customers with their work. These patterns, left unaddressed, could ultimately stifle innovation.
Enough of the doom and gloom. What can we do to make our billing systems suck less? Adopt flexible systems that allow us to evolve our billing as customer needs and market demands shift, of course! If this sounds like a pipe dream, it's not. According to Openview Partners, the technical stack for handling this problem continues to evolve by the day. More and more companies opt to employ products that address this job-to-be-done rather than spend resources building and maintaining these systems in-house.
The ideal solution would allow your company to shift billing paradigms and ship new pricing and packaging in a fraction of the time it would take if you took on the work yourself. It would support changes to your billing system that took minutes, not months, offering insights that help you meaningfully iterate on pricing. Finally, the solution should free up internal resources so teams can return to doing the work they love, creating customer value.
At Stage, we're actively working on solving this problem. We'd love to partner with you on this journey and hear your thoughts as we build solutions that tackle issues teams are facing with their home-grown billing systems. If you're interested in learning more, contact us at email@example.com.