Disha Agarwal - Reo.Dev (00:00)
Hello everyone, today we going to discuss a problem that almost every DevTool company runs into, often much earlier than expected, which is billing. Billing sounds very simple to begin with, right? You charge per seat, per usage and maybe add in a couple of tiers. But as DevTools continue to grow, billing becomes one of the hardest systems to change and one of the biggest blockers of GTM velocity. To unpack why this happens and what can teams do to avoid painful rewrites,
I'm joined today by Fynn Glover, who's the founder of Schematic, a company which works with DevTool teams as they scale billing, usage, and feature access. Fynn welcome, and thank you so much for taking the time today to speak to us.
Fynn (00:43)
Thank you so much for having me. Pleasure to be here.
Disha Agarwal - Reo.Dev (00:45)
Perfect. Fynn So the food will begin and get into billing. Would love to understand your background and what led you to start Schematic.
Fynn (00:53)
Yeah, thank you. My background, I've mostly been a founder and an operator. I started my first company in 2011 and ran that company for most of the next 10 years. We did a lot. We pivoted from services to SaaS. We built sales, marketing success. We raised angel capital. We raised venture capital. We pivoted. We got pricing right. We got pricing very wrong. We were eventually acquired.
And after that company, I joined a Series C cybersecurity company that was growing quite quickly. I managed pricing and packaging was one of my remits. And I sort of experienced firsthand how difficult it was for a scaling business.
Disha Agarwal - Reo.Dev (01:31)
Okay good.
Fynn (01:44)
truly leverage and control pricing and packaging, to make pricing and packaging sort of an extension of the product, to evolve and iterate on pricing and packaging continuously. And that experience led me to getting very curious about the underlying technical and architectural constraints.
which led to the founding of Schematic in June of 2023. So we've been building Schematic for about two and a half years now.
Disha Agarwal - Reo.Dev (02:13)
And how has it been for you, Building Schematic?
Fynn (02:16)
Great. I think ⁓ if you think about B2B monetization, it's actually quite a boring subject for the last 15 years. ⁓ And the reason for that is it just didn't change much. It was just like static and seat-based pricing or billing.
And over the last two years, obviously, that has changed meaningfully. Effectively, what's happening is AI is, of course, ⁓ changing that dynamic. And the reason it's changing the dynamic is AI is forcing companies to operationalize new realities, certainly on their underlying costs.
which are far less predictable, more than that, ⁓ that's a big part of it, but more than that, AI is forcing companies to reassess how they align pricing with value. ⁓ And so what you see is not just a shift from seat-based pricing to usage-based pricing. That's a simple way to look at it. What you really see is a shift from seat-based pricing to lots of different flavors of hybrid pricing.
Disha Agarwal - Reo.Dev (03:08)
Understood.
Fynn (03:25)
not to mention multiple go-to-market motions and multi-product offerings. And so, you know, the way we operationalize pricing and packaging across that type of complexity, hybrid billing, hybrid selling, multi-product, is actually quite, quite difficult.
Disha Agarwal - Reo.Dev (03:42)
and other teams catching up, do you feel that you know now a lot of hybrid pricing is happening and if you could unpack hybrid pricing a bit that would be super helpful.
Fynn (03:51)
Yeah, sure. So like, it, sort of is another proxy for saying something like multi meter, but you know, one of the core principles of pricing is that you price on value, ⁓ as opposed to pricing on cost. Like one of the worst things you can do is price your cost and then add some margin on top.
Disha Agarwal - Reo.Dev (04:11)
Yeah.
Fynn (04:11)
The best thing you can do is deeply understand your product's value to the end customer and then price against that value. so traditionally, one of the best ways to understand your value was to select a price metric or a value metric that was intuitive to the customer. And I'll try to make that really clear. Like in the days of seats, right, a seat
was very intuitive to the end customer on this is how this product's value will expand. The more people using the product, the more the value expands, therefore we're happy to pay more. But when you move into a world of hybrid or usage base, what you start to introduce are new value metrics and in fact, multiple value metrics.
Disha Agarwal - Reo.Dev (04:47)
I'm just gonna shut up.
Mm-hmm.
Fynn (05:03)
And it is sort of embedded in this idea of multiple value metrics that you find hybrid pricing, which can come in many different flavors. Like for example, one example of hybrid pricing would be a platform fee plus usage. Or another example would be like usage-based tiers or volume discounts or ⁓ usage fees with a spend cap or, you know,
Disha Agarwal - Reo.Dev (05:19)
Understood.
Mm-hmm.
Fynn (05:30)
platform fee plus a success fee. Like you can rattle off like 10 different flavors of hybrid pricing, but what it comes down to are multiple metrics of value that are driving the price for the customer.
Disha Agarwal - Reo.Dev (05:43)
I think that context is really helpful. ⁓ And for people who might not be aware, how do you explain what schematic does in really simple terms?
Fynn (05:53)
Yeah, well, I think the way I'll start is just by articulating some of the problems that companies run into. So when you think about a company that is trying to support hybrid pricing and maybe trying to support hybrid pricing across a sales led motion as well as a product led motion and maybe across multiple products.
What you run into is a lot of permutation potential, a lot of skews. And, you know, what companies increasingly want to do is they want to be able to experiment and iterate on pricing and packaging and evolve pricing and packaging rapidly so that they're learning faster and also so that they can effectively align pricing and packaging with ongoing product maturation. You know, like it's a huge missed opportunity to spend two years
of production engineering ⁓ investment and then not adjust pricing and packaging at all because now your pricing and packaging lags the value you've created. So what we see is that it's very difficult for companies to evolve and iterate on pricing and packaging across hybrid pricing models, across hybrid sales motions, across multiple products because of architectural issues
Disha Agarwal - Reo.Dev (06:53)
Thanks.
sure.
Fynn (07:09)
the way we handle what are called entitlements ⁓ is often very much an anti-pattern. so an entitlement is what should someone be able to do in an application? Should they be able to access a feature or exceed a limit or add a seat?
Disha Agarwal - Reo.Dev (07:12)
Mm-hmm.
Yes.
Yeah.
Fynn (07:24)
that historically companies
have hard coded into their application and then tried to tie to plan IDs in the billing system. And the moment that happens, ⁓ type of painful commercial and technical debt is kicked off that's very hard to recover from
Disha Agarwal - Reo.Dev (07:32)
about it.
Fynn (07:43)
And so what Schematic is trying to do is solve those problems, decouple entitlements from application code so that commercial personas and product and rev ops can, with a great degree of agility, control pricing and packaging, not simply from the launch of a new pricing model.
but for the day-to-day life cycle management of a customer,
Disha Agarwal - Reo.Dev (08:01)
Mm-hmm.
Understood. And what stage of companies do you work with? Is this a problem when companies scale or do feel that, you know, even in early stage, ⁓ people are not able to be as agile about pricing as they should be?
Fynn (08:14)
It's a great question. So we typically serve what I would describe as like scale up or mid market companies. These are companies that have usually, you know, gotten to product market fit. They're starting to become more complex. Maybe they're introducing hybrid pricing or they're introducing hybrid selling or they're going multi-product. but this, but this is, this is a problem that exists across market segments. It's absolutely an enterprise problem.
Disha Agarwal - Reo.Dev (08:39)
Mm-hmm.
Fynn (08:40)
⁓ And it's also increasingly a startup problem. What I would say is what we notice is more startups are going hybrid pricing and wanting to be more iterative earlier in their life cycle than they used to be when the world was largely seat-based.
Disha Agarwal - Reo.Dev (08:56)
Understood. You mentioned that a lot of problems sort of comes because of hard coding billing logic. So why do so many companies or so many early DevTool teams actually hard code billing logic directly into their application?
Fynn (09:10)
I think it's a great question. mean, I think in one hand, like when you have very few customers and you've got simple pricing, hard coding it is easy. And you know, what you're kind of biasing for is speed and survival at that stage. You're not, you're not biasing for, you know, the cleanest possible architecture. And so that's, that's one reason is like, you're trying to survive. This is easy. This is fast.
and we don't know what's going to happen in the future. That's a big part of it. I think the second reason is the existing infrastructure and tools have not articulated a standard for how to handle entitlements. And that's something that Schematic hopes to contribute to is, hey, there is a great way to do this architecturally that's clean and scalable ⁓ and great application design from the very beginning.
Disha Agarwal - Reo.Dev (09:57)
Thank
And when you say hard coded, what does that actually look like in a real code base and what would technical debt be?
Fynn (10:09)
Well, I think, I wish I could share a screen here.
So what you're looking at, is like entitlements data that is, it lives in the billing system. It might live in your code. It's effectively these if-then conditionals based on what the customer got,
that the engineer has had to consider and that the engineer has hard coded. And so what's the implication of this? Well, anytime the business wants to go make changes, whether they are really big changes, like we're going to introduce an entire new pricing model with credits and new price metrics to like a really simple change. Like we're going to grant an exception on this enterprise deal because they're an enterprise and we need to get them across the line. You got to come back into the code and you have to make the changes here.
Disha Agarwal - Reo.Dev (10:47)
shot.
Yeah.
Fynn (10:53)
And what this looks like when you have decoupled all of this is it looks much cleaner, right? Like you're basically, you're putting all of this billing logic behind this centralized entitlement check that works like a feature flag. And so what it allows the developer to do is simply ask this service, can the user do this? Can they exceed this limit? ⁓ Things like that. And it's basically a separation of concerns. Now the application.
Disha Agarwal - Reo.Dev (11:01)
for coming.
Okay.
Fynn (11:22)
doesn't have to know about all of this billing state, which it shouldn't have to know, it can just ask schematic or ask the entitlement service that you build in-house.
Disha Agarwal - Reo.Dev (11:27)
Mm-hmm.
Fynn (11:32)
handle that in your code and across lots of different business systems.
Disha Agarwal - Reo.Dev (11:37)
Understood. So once someone starts working with schematic, what is the first step and how do you actually help them clean up their billing logic so that it's more sustainable, more agile?
Fynn (11:47)
It's really quite straightforward. So we integrate deeply with billing platforms. Most importantly, we're deeply integrated with Stripe. effectively what you do is you connect Stripe that imports all your customers into schematic and all your products. Then you set up features and plans and schematics. So I like to think about features or entitlements as sort of the atomic unit.
for how you want to monetize your product. And what you do in Schematic is you create three types of features. One could be a ⁓ of a Boolean feature on or off. One could be an event-based feature, which might be like something like API requests that you're tracking and metering against. One could be like a trait-based feature, which might increment or decrement, for example, a seat. You know, are you going to add five seats in this month and then subtract two next month?
Disha Agarwal - Reo.Dev (12:22)
short.
Mm-hmm.
Fynn (12:39)
So you can create these features in Schematic and title them to plans. And now you've got a product catalog. ⁓ any change that you make in Schematic kicks off a change that propagates in your application to correct access and also a change downstream into the billing tool to ensure correct invoicing.
Disha Agarwal - Reo.Dev (12:44)
Mm-hmm.
And which use case do you see happening the most across the companies that you work for?
Fynn (13:07)
Well, so we, we, what we see is basically like, there are kind of three very kind of like core value pillars. The first is for engineering. You now do not need to build and maintain a robust and decoupled entitlement service. You've offloaded that. And what that does is it basically allows you to centralize how you manage state, customer state. that's very important. And the second piece is more for.
Commercial personas and so what commercial personas are trying to do a schematic is generally two things one is launch new pricing experiment with pricing this might be introducing a price model and that might take place a few times a year depending on how fast they're shipping
Disha Agarwal - Reo.Dev (13:45)
Yeah.
Fynn (13:49)
For example, a very common use case is I need to understand, ⁓ which of my customers are overusing the product, but underpaying relative to other customers so that I can go try to expand them or this customer has hit a limit. I need to alert sales that it's time to go have a conversation. You know, it's
Disha Agarwal - Reo.Dev (14:02)
Mm-hmm.
Got it.
Mm-hmm.
Understood.
Fynn (14:13)
all kinds of little jobs like this
that allow you to leverage packaging to drive more expansion out of your customer base.
Disha Agarwal - Reo.Dev (14:19)
Understood.
Fynn (14:20)
what we often talk to companies about is like, how should I approach pricing and packaging from like a strategic perspective? And the second question that we're always handling as well,
How should I architect pricing and packaging so that from an infrastructure perspective, we're super agile? And so what I would say is, to answer the first question, what I see from the best companies, the companies that are really turning pricing and packaging into a growth lever.
is that they actually view pricing and packaging as something that they should be good at. You know, they sit there and they say to themselves, we should be as good at pricing and packaging as we are at sales or engineering or product or customer success. Like it is that important. And when they have that type of commitment, what I then start to see them do is sort of incorporate and almost like a practice or a function, several things. One is
They continuously go out and have willingness to pay conversations with the market. They're constantly pressure testing their value. The second thing is that they internally, establish pricing principles that are aligned with their stage because if they don't have principles, they can be really reactive and inconsistent. ⁓ the third is that they make pricing conversations like a legitimate habit. They have monthly meetings.
Disha Agarwal - Reo.Dev (15:16)
got it.
Mm-hmm.
Mm-hmm.
Okay.
Fynn (15:39)
to discuss what they have learned from the market about their pricing and their packaging. ⁓ And that kind of translates finally into they're committed to aligning their core product roadmap with a pricing and packaging roadmap. They want those two things operating in sync because they believe it will make them more money. So that's the strategic side and that's the best practice I see.
Disha Agarwal - Reo.Dev (16:01)
quality.
It's not like, you know, every year you're sort of figuring out what your pricing should be or, you know, per feature, this is what the pricing should be. You're also understanding what the market is doing, what is it that they're using and then basing your pricing based on that.
Fynn (16:16)
That's right, that's right, exactly. like, you know, I think we're moving into a world where, like we are coming from a world where many companies ⁓ left a lot of money on the table because they did not treat pricing and packaging as this core muscle to be exercised continuously. And I think that what that means is companies that really treat pricing and packaging as a discipline.
Disha Agarwal - Reo.Dev (16:36)
got it.
Fynn (16:41)
will grow faster and be more competitive and be faster to iterate and learn.
Disha Agarwal - Reo.Dev (16:47)
But how does the market react when you are your pricing so often or if you are including new tiers? Do they see any pushback because their pricing is continuously evolving or is that something that the market accepts because the product is also evolving?
Fynn (17:02)
Great question. I think the answer is yes, the market accepts continuous iteration. However, what I would say is if every three months you make a massive change to list price or price metric, that could be damaging. Whereas if every month you make a change to packaging because your product got better, that's very positive.
That distinction is very important and I'm happy to elaborate on it if that would be helpful.
Disha Agarwal - Reo.Dev (17:29)
Yeah, if you could.
That was supposed to be my next question. If you could elaborate on what you mean by packaging and how is that different?
Fynn (17:35)
Yeah. So like, let's, let's imagine you're, you're selling B2B software to enterprises and, ⁓ you know, you've got a pricing page and that pricing page has three tiers. And let's say your sales rep is trying to close an enterprise deal and that enterprise customer is familiar with the pricing on your pricing page. And let's say that enterprise deal takes three months to close and let's say you're getting farther along in the deal and then.
two months in, the customer sees this like big change to your price, like the actual list price. And they also see a big change to your value metric. Like you've gone from seats to credits. Well, now that negotiation is at risk, right? Especially if there's been poor communication. And so that's why major pricing changes like the actual price or the price metric.
Disha Agarwal - Reo.Dev (18:15)
short.
Fynn (18:28)
happen far less frequently than packaging changes. Because if you're shipping new features all the time, you in theory should be adding new features into the enterprise tier, pulling enterprise features back into the startup and growth tier. Your packaging can change all the time, as it should, ⁓ whereas your pricing, like the actual price point, might change less often.
Disha Agarwal - Reo.Dev (18:48)
Makes sense.
Mm-hmm.
got it. For your packaging changes you're saying that even if it's like a monthly sort of shift that's something that the market accepts because the product is evolving.
Fynn (19:05)
That's exactly right.
Disha Agarwal - Reo.Dev (19:07)
Got it. And so this is helpful. And the second question, Fin, you were saying, how do they think about pricing from an infrastructure perspective so that they can be more agile? So if you could elaborate on that.
Fynn (19:17)
the pattern that most companies start out with is they implement their billing tool, Stripe or ChargeBee or whatever, and then they have their application know the billing state of the customer, meaning they've hard coded the entitlements. And this is ⁓ not good application design.
Disha Agarwal - Reo.Dev (19:20)
Mm-hmm.
Mm-hmm.
Fynn (19:38)
because it tightly couples billing state, billing logic in your application and means, and basically kicks off that cycle of commercial and technical debt because pricing and packaging will inevitably change all the time, many times for the rest of the business's life cycle. Meaning you're always going to have to go in there as a developer and support the next billing or pricing iteration. so whenever you
Disha Agarwal - Reo.Dev (20:03)
Yeah.
Fynn (20:07)
kind of get into a billing implementation and you accept this inflexible pattern of having billing state be known by the application. What you're doing is you're making it really hard to evolve pricing and packaging and support customer exceptions as your product grows. A much better way to do that is to either build a decoupled entitlement service or buy a decoupled entitlement service.
Disha Agarwal - Reo.Dev (20:25)
got it so so it
Fynn (20:34)
so that your application does not have to know the billing state of the customer. That's the key point to set your pricing and monetization architecture up for scaling.
Disha Agarwal - Reo.Dev (20:45)
So what does this clean architecture look like? So I understood, you know, buying a decoupled sort of service, but if one were to build it, how does it look like?
Fynn (20:53)
Well, the thing that you're trying to do, right, is you're trying to build a service or buy a service that, you know, effectively can describe entitlements and evaluate entitlements and enforce them in the product at runtime. That's what you're trying to do.
Disha Agarwal - Reo.Dev (21:12)
Got it.
Got it. And you see a lot of companies now doing this. Is there like enough awareness about the agility of and the importance of pricing or do you feel that this is something that that companies are still catching up to?
Fynn (21:27)
I think it's both. I think what we have learned is there's an enormous amount of pressure up and down the stack companies of all sizes to figure out hybrid pricing. And, if you think about the reason for that, it's. You know, it's it's effectively like it's kind of twofold, right? It's like you could dumb it down to like, well, AI is making everybody go do hybrid pricing, right?
But what's really happening is software is becoming more probabilistic, which means variable outputs and costs at runtime rather than deterministic, where the same inputs yielding the same result. And that makes static seat-based pricing break down. And so in response, every company is having to figure out how to adopt hybrid
Disha Agarwal - Reo.Dev (22:05)
Mm-hmm.
Mm-hmm.
about it.
Fynn (22:20)
pricing usage aware models, not just because they're trying to protect margins. That's one part of this, but it's really so that they can align price with value and maintain control as software becomes more dynamic.
more companies are starting to realize that they're running into all these kind of flexibility problems. And when they reach out to us, what we often find is they're kind of blaming their billing product. They're like, our billing product isn't flexible enough. what we often find ourselves doing is helping them understand, well, actually, this might not be a billing problem.
Disha Agarwal - Reo.Dev (22:44)
shows.
Fynn (23:01)
This might be an entitlements problem. This might be how you've implemented monetization in your code. And most of the time that is the problem.
Disha Agarwal - Reo.Dev (23:06)
Understood.
Understood. And is this like the biggest problem that you see in pricing that companies make or the biggest mistake that they make?
Fynn (23:17)
man. Well, I think it's those two. It's like either they don't treat pricing as a discipline to excel at as a business. And that's a strategic, ⁓ that's a strategic missed opportunity. And then secondly, they don't think about pricing as this full architecture that must be able to interact with their product, their billing, their quoting, you know, and so they end up with all these silos and then unable to iterate. Those are the two common problems.
Disha Agarwal - Reo.Dev (23:48)
So someone who is starting a dev tool, what would your piece of advice be for them when they are thinking about building?
Fynn (23:56)
So there are lots of good billing tools. ⁓ I think my main advice to them would be when you set up the billing tool that you choose, do not hard code entitlements. Do not ask your application to be sort of the source of truth for billing state because it will just make your life miserable as you grow and as your product becomes more complex. And it's very easy.
to solve that problem in the early days. It can be quite expensive if you get to 10, 20, $50 million in revenue and you've got multiple products and thousands of customers to go unwind that. So mean, many companies end up with like large billing engineering teams because of this.
Disha Agarwal - Reo.Dev (24:34)
and
Understood. No, I think this is quite insightful because I don't think from what I'm understanding is that billing is one of those things that teams don't really think about enough until it starts becoming a bottleneck. So I think this is really helpful. And I think thinking about pricing as a discipline is something that is fairly new and something that I hadn't thought of. So super insightful, Finn. Thank you so much for sharing this.
Fynn (25:05)
I'm so grateful to be here. Thank you for having me. Thank you for the great questions.
we just released a book. ⁓ so much of what we've discussed is packaged in that book and you can read it in under an hour and get, you know, basically everything that we've learned about pricing and packaging across 10 years of operating, 10, 15 years of operating.
Disha Agarwal - Reo.Dev (25:24)
What's the book name? We'll at least make sure that we link it when we're releasing this episode.
Fynn (25:30)
It's called, you're leaving money on the table. it's a really good, I think it's a really useful read and it will touch on kind of the two core things we talked about, which was like, how do you make pricing a discipline? And then how do you architect pricing for flexibility?
Disha Agarwal - Reo.Dev (25:33)
a very interesting title.
Anyway.
Fynn (25:46)
Thank you so much, great to be with you, appreciate it again.
