In this excerpt from a YouTube discussion, the speakers examine a common early‑stage architecture mistake in B2B SaaS products: embedding billing state directly into application code (e.g., a trial/subscribed/canceled flag on a user or organization record). This tight coupling creates operational friction, especially when handling special‑case customers (such as manual invoicing or delayed wire payments) and when product teams need to modify plans or add features. The conversation proposes a more flexible pattern—introducing an entitlement (or feature) service that sits between the application and the billing system. Instead of checking a hard‑coded billing flag, the app queries the entitlement service with an organization ID and a feature name, receiving a simple true/false response. This abstraction isolates billing complexity, enables rapid plan changes, supports one‑off cases without code changes, and streamlines UI/API gating. The speakers conclude that moving billing logic out of the core codebase into a dedicated entitlement layer is a low‑effort, high‑impact improvement for scalability and agility.
You said a lot of the complexity comes down to the way we've integrated with billing systems early on. What is the relationship between the actual product and application code and the billing system typically early on based on what you've seen?
Yeah, so I think early on, a simple but kind of inflexible pattern is having your application know kind of the billing state of the customer. So having, you know, in the simplest case, just a field on the organization or the user that says, you, you know, in trial, subscribed or canceled, and then making decisions based off of that. So it's coupled really closely with kind of the state of the billing system. And that causes issues when you go to change things, but even early on it causes issues. You know, if you have, I feel like early on there's always the special case customer of like nobody else gets invoiced, but you have, you know, customer ABC that is going to pay you by wire 2 weeks after the fact and you need to handle that case. In that architecture of having it the user state be coupled directly to billing, it's hard to handle that. You end up having to do a bunch of like manual support things or having a developer change values in the database to make that work. So a more flexible version of that, that's not really that much more work is having the billing and the application be decoupled just with the idea of like features or entitlements. So instead of saying, hey, this organization is subscribed, they're in a good state, you can just have a service that you give the organization ID and say, hey, they want to send a message. You know, have they paid for that? Feature, or are they allowed to, or, you know, that logic's kind of abstracted away. So you just have organization ID, name of the feature, and then true or false. Your application then can decide, you know, do we show different things in the UI? Do we have different API endpoints available, whatever it is based off of that, but it's not tied directly to billing cycles or any of the kind of complexity there that all can kind of get abstracted away. So having that idea of feature entitlements, like what is, what are they allowed to do? Lets you change over time. Like, hey, these 5 features are being added into that plan. So now suddenly they get access to it. You're not changing any code in the application. It's just the response that comes back from that one service. So that makes things much more flexible. Even in those cases where you're having to do one-off things, you're hiding that behind that kind of feature service.
So just to play it back, early on, many companies make the mistake of effectively hard coding business logic from the billing system into their application code. You could avoid that if you simply just built an entitlement service that sat between your application and the billing system and decoupled the business logic from the code.
Yeah. And it, you know, for a very early stage startup, that might mean that there's manual invoicing going on behind the scenes and you're just flipping the switches per user of, you know, what they're allowed to do. But that still, it gives you a lot of flexibility there as to changing really quickly your, your pricing model. Being able to iterate on it. And then down the road, it opens the door to the pricing patching that's inevitably going to change because of, uh, your growth.
