In this conversation, the speakers diagnose a common but critical mistake in SaaS product design: hard‑coding pricing, packaging, and entitlement logic directly into the application code. They explain how this creates massive operational headaches as companies scale, especially when dealing with enterprise customers who require complex arrangements such as pooled credit allocations, subsidiary plans, and nuanced usage limits. The discussion then pivots to a solution—decoupling the entitlement layer from the billing/ERP layer—so that product features, usage quotas, and plan definitions can be managed centrally and communicated to downstream systems (CRM, billing, APIs) without touching financial records. They argue this separation enables rapid experimentation, cleaner feature‑flag‑style control, and reduces the risk of accounting errors, while noting an exception for ultra‑simple, static products that never change. Finally, they highlight an education gap: many SaaS founders only discover the pain after reaching larger customers, and the speaker’s blog post aims to share the hard‑learned lessons to help others avoid the same trap.
Chapters
years.
Restate what I think you said. The root technical complexity of making changes to pricing and packaging, evolving pricing and packaging, often comes back to pricing and packaging being hardcoded in the product.
That's my impression.
I think that that's a common experience. I recently talked to somebody who said something similar. I was like, what do you think is like making this so difficult? And he said, we've hardcoded pricing and packaging logic. You know, effectively what we've done is we've hardcoded the entitlement into the application, tied it into a plan ID.
Yeah.
And then he sort of went on to lament, you know, what SaaS companies should be able to do is define an offering, have it flow through to their tools, their product, their CRM, their billing system, web API presence with offering name, features available, usage quotas, rate limits, etc. It should be defined once. It should be inherited across the application, inherited across the business systems. But that is not possible to my knowledge. And I thought it was like profound, like that is not possible. And that is, you know, an incredible constraint on how iterative you can be as a company.
We can talk about a reason, like an example of a reason why that might not be possible. Imagine a situation where you've signed, especially in B2B, imagine you've signed up a company and you want to allocate, you know, 10,000 credits for them, right? That's part of their deal. They get 10,000 credits. But then they say, hey, listen, we have some subsidiaries. We want them to be on our own plan. So you create a new entity in your system. Now they need to derive the same, or they need to share the same amount of credits. They might want to tell you, hey, but okay, this subsidiary, we want them to be part of our pool, but we don't want them to abuse our pool. So we might want to limit them to 1,000 and the rest get 9,000. That gets really complicated. That's complicated on a contract, on a quote side. It's complicated in your CRM. It's going to be complicated, you know, really complicated to do in your product. It's going to be complicated on the metering. It is actually legitimately complicated. It's impossible to build for that. So, you know, you have to kind of make decisions for your customers on this is what I'm going to allow. Again, the problem is you don't realize that when you're building your product in the first days. You realize that only when you get to the more enterprise customers, when you get to like a bigger scale and you've been exposed to it. And suddenly your old— the, the product that you thought was suitable for everyone turns out it's kind of suitable, but it creates an operational mess for them.
I want to go to the post that you wrote about entitlements and billing. Is a valid solution, based on your experience, the decoupling of pricing and packaging logic from the code base, the decoupling of an, an entitlement service from the billing system? Is that generalizably beneficial to companies and kind of based on what you've seen so far. And maybe, maybe that's a big question. Maybe you could just kind of say again, why did you write the post? Why did you argue that entitlements and billing should be separate?
Uh, the pains that we went through with hard coding made us realize that we needed a more robust way to kind of give access to customers in a way that doesn't touch the financials. Financials are sensitive. If I change a customer from one plan to another, it gets reported. It needs to get, you know, go all the way to the ERP. If I've just created a new product just for them, then we need to make sure that that gets into the right kind of journal in the ERP. Someone needs to, you know, map those, this code to that code, this SKU to— it becomes an operational disaster. Then you get customer support going in and being like, what plan is this customer on? It doesn't populate correctly. I'm used to them being on this plan. They're on that plan. What's going on? So we decided that we, you know, we have fairly rigid pricing, but we want to control the experience that customers have. We might want to give them an extra feature. We might want to limit features for legal reasons. We might want to remove them. And the realization that we don't want that to go all the way down to the ERP and to the bookkeepers and the, you accountants. That's what led us to this kind of, uh, understanding. Now the same thing can be said for pricing experiments. Uh, you might not want to create a new SKU for every different price that you make. It's nice to version them if, if you're doing like, from now on this is our price, we're not going to change it again for a year. You can have a new version. You might not need to run experiments that frequently. But for most, uh, companies, they're still kind of searching, they're still trying out different things. So, as you said, separating that logic and maybe having its— this own service that can handle the pricing, the pricing pages, the, the signup flow, having a different service that can control what you get, what features you get, and having a separate service that can do the invoicing and the charging of, of, of the payment methods. It makes sense to separate them. They should be able to talk. There should be something that kind of negotiates what this means and what that means. But the— there should be kind of like a unified definition of, of what your product is, what features you have. And the sooner you break that apart, the better. There is one exception to that. If you're selling a very simple product and you don't think you're ever going to change that, or you're not going to expand internationally, you don't think you're going to price it any differently, don't bother, right? But if you're starting a company and you, you want to grow and you think you're going to change your product over time, which is what most companies should be doing, increasing value, adding more features, adding, you know, new ways to do something, you have to plan for that. Engineers do this all the time, by the way. Feature flags, right? That's— it's kind of close to entitlements. Engineers have got their solutions worked out for them. That's worked out. For the more businessy things, for pricing and for that packaging and entitlements, it's more of an afterthought today. There's an education piece that's missing that a lot of companies don't really get to until they reach the point where it hurts, and then they seek out the solutions. And I think that's why I wrote that blog post. It's like a little bit of education, like to share, we reached this, we, we got to this, this is
