How to Design a Better Billing System for Your Startup
How to Design a Billing System for Your Startup
With the growing demand for product-led growth strategies, the hidden technical debt of billing systems is a looming issue many organizations overlook. Startups can create opportunities for improved profitability and diverse revenue streams by anticipating the pitfalls and blockers that unoptimized billing systems can introduce. For example, activities we consider to be “billing” may actually be completely separate processes such as accounting and payment processing–each of which is a complex area that can carry its own issues.
However, if startups can proactively address billing system issues and prevent technical debt across complex subscription models to customer onboarding, billing systems often provide the backbone to startups scaling their go-to-market from the bottom up. In this article, we'll explore the hidden technical debt of billing systems and how to address it to ensure successful product-led growth.
What is “Billing System Technical Debt”?
You could define billing system technical debt as the ongoing opportunity cost of not updating, optimizing, or otherwise improving your startup’s billing system despite changes in your product offering, ideal customer profile, or competitive landscape. Over time, many aspects of successful startups evolve, including product lines, product pricing, customer account sizes (in some cases, moving upmarket from “smaller” individual customers to multi-million-dollar enterprise-scale customer accounts), and many others. Sticking with a single, outdated billing system long past its expiration date can be painful and costly.
I’ve seen the particular problems of billing system technical debt manifest in every tech company I’ve worked for, some more than others. While I was working at Box, the platform SKU pricing was volume/usage-based. However, the product's value wasn’t reflected in a price-per-API call model. In exploring alternative pricing models, we uncovered a traceability and reporting problem that had yet to be addressed before my departure. Situations in which data infrastructure and analytics problems eventually become billing problems can be more common than we might think. After all, how can a company accurately charge for data usage when it can’t accurately measure data usage?
Mergers and acquisitions can also cause billing headaches when acquirers and acquirees have significant differences in the way they price and package their offerings. Reflecting on Microsoft’s acquisition of GitHub, Microsoft’s customers anticipate usage-based pricing, while GitHub is somewhat stuck with seat-based pricing. There are exceptions; GitHub introduced pricing calculators for Actions, Packages, and Codespaces with the intent of reducing confusion between the buffet of product portfolio pricing.
Somewhere in the middle of these companies, you’ll find Atlassian, with every price listed on its website (discounts are only available through agency partners), or OpenAI, where usage-based pricing is the same for organizations or individuals but offers a concrete example to help orient users. Not to say that there’s one “correct” way to handle billing for every developer-first startup across the board, but there are certainly important factors for every company to consider.
OpenAI’s pricing model offers multiple token-based pricing models.
What to Watch for in Your Billing System
Let’s look at some examples of the most significant causes of technical debt for startup billing:
Managing Multiple Billing Models Adds Complexity and Tech Debt
The first-order problem of billing system technical debt is the complexity of combined billing requirements for enterprise sales and self-serve funnels required for product-led growth, especially for developer tools. With enterprise sales, customers typically require invoices that contain a variety of line items, discounts, taxes, and other information. To produce these invoices, billing systems must be capable of managing complex pricing models, letting customers pay in different currencies and supporting multiple payment methods.
The challenge is that as startups try to accommodate so many of requirements, ranging from freemium models to custom-negotiated net-30 invoices, they can accumulate significant technical debt in their billing system. Let’s reflect on the history of hosting costs and payment models as an illustration. Shared hosting for consumers on Bluehost is $2.95/mo with a 12-month contract. Alternatively, Azure offers free service tiers but compute usage has a capped limit. A flat rate charged to a credit card is often more comfortable for an individual user, while a business will optimize for costs due to its operating scale.
Why We're the Leading Dev-First Investor
Learn how to unlock success for your startup from pioneers in the developer-first space. We send the best strategies, tools, and industry updates directly to your inbox.
Not Being Able to Scale for Increased Demand Adds Tech Debt
The second-order effect of combining product-led growth strategies with end-game enterprise sales is scalability, both in engineering talent and transaction volume. If your product-led growth strategy is successful, you’ll be bringing customers directly into your funnel via a bottom-up model, such as through a free trial or other landing page on your website, rather than having access to your product gated by formal sales conversations. Some of the most successful software companies in recent years, such as Miro and Notion, started from a grassroots approach, directly engaging the user community and enabling them to immediately jump in and start engaging with the product.
Going bottom up can be an extremely economical way to grow your business, but the billing systems must be able to keep up with the demands of the customer base. Your system must be able to handle increased transaction volumes, process payments quickly and accurately, and provide customers with a seamless experience. Adding enterprise sales to a bottom-up strategy can be a sharp corner to navigate for startups that aren’t prepared.
If the billing system can't scale as the customer base grows, it can create a bottleneck that can cost the company time and money, and may even lead to user experience and customer satisfaction issues if they cause significant delays or billing errors. Internal tooling teams, such as those maintaining custom billing systems, often need more investment from engineering and business leadership. This can be a secondary opportunity for bottleneck as demand for new pricing models and features increases.
Conclusion
Billing, authentication, and authorization are common early areas of investment. Still, since they aren't the core competency of most startups, those same domains are often left under-resourced and highly dependent on internal customers with little room for future bets. There are exceptions: companies who understand these shortcomings and invest in internal tooling teams, companies that offer billing or auth services and dogfood it.
By comparison, a SaaS billing system is likely investing in new areas like payment orchestration, support for multiple currencies, tax requirements or support for tax providers like Avalara, and more-complex billing schemes. It doesn't remove all the pain that can be introduced from usage billing, overage enforcement, etc but I have observed frequently revisited pain where billing engineering with a custom-built system becomes the bottleneck for portfolio expansion. Given current market conditions and the increasing focus on product-led growth, organizations must recognize the impact billing systems have on their success.
The disparate billing needs between product-led growth and enterprise sales can create difficult-to-manage technical debt. And unless you have a team of engineers who specialize in building and maintaining billing software, I strongly recommend founders consider buying versus building, especially after seeing the compounding effects of internal billing systems blocking golden paths for go-to-market strategies.
More Resources
Content from the Library
O11ycast Ep. #67, Managing Infrastructure Costs with Performance Engineering
In episode 67 of o11ycast, Martin, Jess, and Liz dive deep on performance engineering. Pulling heavily from Liz’s extensive...
Unintended Consequences Ep. #13, The Thing About Consultants with Corey Quinn of The Duckbill Group
In episode 13 of Unintended Consequences, Heidi Waterhouse and Kim Harrison continue their conversation with cloud economist...
Unintended Consequences Ep. #12, High Score Bills with Corey Quinn of The Duckbill Group
In episode 12 of Unintended Consequences, Heidi Waterhouse and Kim Harrison speak with Corey Quinn of The Duckbill Group....