How Schematic changed its pricing in Spring 2025

Hey everybody, welcome to another edition of Monetizing SaaS. This is going to be a little bit of a unique episode for us. We are going to not do a teardown of another company's pricing page or billing experience. In fact, this time we're going to do a teardown of our own pricing. Um, we recently rolled out an overhaul to our pricing and packaging, and we want to talk through how we went about that, why we did that, um, key decisions that kind of guided the process for us. We'll also talk a little bit about how we used Schematic to roll out the changes, effectively how we dogfooded our own product. So it's going to be an interesting episode with me as always, Schematic co-founders Ben and Gio. I think let's do this. Gio, why don't you go ahead and pull up our pricing page and I will just give a little bit of a brief introduction as to what's driven this and what's kind of driving this episode. But about, what is it, 2 weeks ago, we changed our pricing. And we changed our pricing because very simply, our product is more valuable than it used to be. And we want our pricing to reflect that. Our original pricing was pretty adequate for our initial cohort of design partners, for early adopters. But as we shipped more and more value every week, in fact, like it, we were taking up mission-critical responsibility for our customers. And it was clear to us that our initial pricing just didn't accurately reflect that new reality. Um, you know, kind of where this started was like, well, how do our customers feel about our initial pricing? And the most common feedback was it feels cheap, it feels like really, really affordable. Um, you know, and that kind of made sense because initially, as we had built early versions of the product and relied on the patience of our design partners and the patience of our early customers, our price points reflected a decision made to price for adoption. We had also wanted to be very simple, so we had gone with simple flat rate tiers, even though we knew that eventually we wanted to move into usage-based billing. But by February of this year, what, what had started to become clear is that our customers were using us for all these mission-critical jobs, from feature flagging to entitlements to plan management. Even to admin panels, metering, usage-based billing, limit enforcement, limit management, and a whole kind of a long tail of billing UI embedded in their application. We were even seeing people starting to use us for product analytics and billing analytics, something that we have aspirations to become very good at, but early stage stuff. And so we were seeing customers replace their existing feature flag tools. We were in some cases seeing them replace their product analytics tools. We were always seeing them replace homegrown billing infrastructure, and we were seeing them use us to get a lot more value out of their Stripe implementation. So the main question that we really wanted to dig into is, you know, what is the right price metric for this type of product? What did our customers think was the unit of value that would be most intuitive? In other words, the, the kind of the price metric that could grow over time as they grew that they'd feel really good about. Should it be flag evaluations? Should it be monthly active users? Um, these were both real contenders given our core product primitive is feature flags, but that didn't feel quite right because the primary value that we provide is helping our customers monetize their subscriptions. So we considered things like percent of revenue, similar to Stripe, or pricing based on customer volume or subscription count. We all had a hypothesis here, but kind of what we eventually did is we just started asking our customers. And what we overwhelmingly heard was customers say that our price metric should be something like monetized subscriptions. And that's because at, at our core, we're helping our customers manage and monetize their subscriptions. So I want to provide that context and maybe Gio, you can kind of walk us through what we did here. What were the core changes? And then we can get into how we rolled it out with schematic.

Yeah, and maybe to zoom in on what is a monetized subscription, this is a— we explain that here in the FAQ, and it's the idea of a subscription that Schematic has allowed you to monetize uniquely through Schematic, meaning it's part of your active Stripe integration, it's a paid subscription, or it's potentially paid, meaning maybe It's an overages-based subscription. So that is what a monetized subscription is. The idea is Schematic is providing the value that allows you to monetize that customer that you would otherwise have to home grow, like whatever internal tooling to make that happen or, or use some other tool to do that. So that's what that is. What it's not is any, any company on a free plan is not on a monetized subscription. Any company that's on a trial, it doesn't require a payment method. Or any company that's in like a test instance of Stripe or Schematic does not count as a Montye subscription. And you can of course track that all inside of our product and make sure you know where you are against the limit. So in terms of what we did on our pricing page, we still have the 3 plans. We now have more usage-based limits on them. So in the free plan, you get 10 Montye subscriptions included. The goal with this free plan is it's an evaluation plan. If you have like a hobby project, it might even be good enough for that forever. But the thought is like, you can use this to figure out if Schematic is a fit for you. You get most features included there. Once you get to the paid plan, you start to get more monetized subscriptions. We're thinking about whether this number is right, just in the, in the spirit of pricing is always evolving. This is something we're getting feedback on. And so we'll keep looking at. You get, you get overrides, you get the ability to offer add-ons, the ability to offer trials, you can remove the schematic branding from, from the components if you'd like. And then finally with Enterprise, you get everything, everything. You get more premium support, you get the webhook trigger as a data export, and then finally we added this add-on, which kind of taking some inspiration from tools like PostHog where you have an add-on that's really meant for teams where you're kind of— your business is growing, you need, you need features that businesses need. In this case, it's unlimited data exports, the timed override feature, unlimited overrides, alerts, and longer data retention. So that is the high-level thing that we changed. Of course, we have a feature breakdown with more detail on what you get and don't get. And then our FAQ. But that's like the high level there.

Yeah, awesome. Well, maybe a couple of things I will add here. Something that felt really interesting to me through this consideration was basically, basically kind of for me, the consideration was this, like if our customers were telling us that our core product is helping them manage plans or subscriptions and entitlements, and that our core price metric should be monetized subscriptions. Well, we then had like several things to think about. Gio's already pointed this out a little bit, but the first was what was, what's the price point and the price band that the market would find intuitive per monetized subscription? In other words, how would our pricing scale? You know, if you have 200 monetized subscriptions, what's the price? If you have 5,000 monetized subscriptions, what's the price? Secondly, we have customers that use Schematic purely for plan and entitlement management, sometimes purely for feature flags. And then we've got customers that use us for our entire suite of monetization tooling. So more advanced monetization use cases like overrides and webhooks and alerts. And components and paywalls and all kinds of interesting things to drive revenue. Should these advanced features be available to everybody or should they be available as add-ons to the companies that are going to be the power users for that type of functionality? It's an interesting question because we really want to promote adoption, certainly at this stage, we're an early stage startup, but these are features that actively drive revenue for our customers. So we want to monetize that. And then thirdly, we have SMB, quickly growing startup customers. We have mid-market customers. We also have enterprise customers. And often with mid-market customers and enterprise customers, they don't want to buy self-serve. They want to buy via at least some conversations and certainly with a contract. And in the contract, they want SLAs, they want premium support, they want prioritized roadmap. How would we consider the difference between enterprise and non-enterprise plans? And so for now, and I want to stress this seriously, we expect— I say for now for good reason. We expect this to change continuously. But what we landed on is 3 things. So our pricing today is driven by 3 big things. This is what I always say to customers and maybe for anybody listening, right? Like one of the things that I I think sellers would be well to think about is what is the story of my pricing that I can easily communicate to my, to my customers? And so our story is our pricing is driven by 3 things. It's the number of monetized subscriptions that you're managing with Schematic. It's whether you need advanced monetization features, which are covered in the Teams add-on. And it's whether you want SLAs for uptime, support, prioritized roadmap, whether you're an enterprise customer. And so that's kind of like the, kind of the key consideration that we had to go through to get to what we've landed on, on this pricing page on this iteration. So Gia, when we use schematic to roll out these changes, talk a little bit about how we use schematic to roll them out.

Yeah, so it was basically two different steps and I'll start sharing what it looks like in our product here. But the first step was a new metric that we need to instrument, the monetized subscription thing, which Ben led the effort on there. He can speak to how that went.

Yeah, I think that was kind of most of it, right? Because this was a change to a pricing metric. We didn't necessarily change like what features we offer. We just changed kind of the limits on them, what plans they're in, things like that. So that was kind of the nice thing here is we were adding a new pricing metric. So we needed to implement that pricing metric, essentially tell Schematic somehow how many monetized subscriptions each account has. So we implemented, you know, just a backend trait-based feature for that where we just keep that updated as subscriptions get created and end and things like that in our customer accounts. And then once we had that, we were able to just switch to using that as an entitlement input, right? And so pretty straightforward actually, just to implement however you want to send the data to Schematic. And then from there you just go into Schematic and specify that as a constraint.

Yeah. And then from there, what we did is we rolled out new plans. So in this case, we rolled out a new growth plan. We just made some changes to the existing free and enterprise plan. And that was really easy. Took a couple clicks, a couple minutes. And then we went into plan configuration here, and we dropped in, we removed the old plan, which was called Team. And we dropped in this new Growth plan, which then means, right? So just for everyone to know how it works, everyone on Team remains on Team. We don't, we didn't force a migration there. They remain on Team, but when they go to upgrade or downgrade, they will only see these free 3 live plans available. And then of course I went in here and I made sure the ordering was correct. I wanted to emphasize monetized subscriptions at the top. I wanted to not show features that are included in the previous plan so that it can say like Growth includes everything from Free Plus. And so I made some kind of UX choices here on what to emphasize. Of course, we have free as the default plan, and then we added this new add-on, the Teams add-on, which has unlimited overrides and webhooks and some other features that other plans do not have. With all that in place, you can now see what the component looks like. So I'll go ahead and, um, let's see a better view for this. I'll pull in Let's see someone who's on a— keep using Lotta as an example. They're on a— they are on a legacy plan. And you can see now when they go to check out, there's those, those 3 plans are available. There's also the add-on if they want it. And that's kind of it. I guess another update we made is on this monetized or this metered feature section here. I updated what is shown. So I wanted monetized subscriptions to be at the top here because that is now our most important metric. And similarly with included features. So I made a couple tweaks, took about 10 minutes total. Most of the work, like Ben said, was just putting in the new metric for monetized subscriptions.

Ben, apart from creating a new price metric, You're our CTO. Were you involved in this at all?

I didn't do any of that stuff. Basically, once the data is in Schematic, there's not really any need for the technical team to be involved per se. Like, unless you want to measure something new or gate something new, which in this case we just wanted to measure one new thing and that was it. So yeah, I was not very involved in anything that Gio just described at all.

Part of the beauty of Schematic. So we've had this live for a few weeks. And curious to kind of get a sense from you kind of what you're learning from the market. And I'm happy to talk about what I'm learning too.

Yeah, I think we've heard the same thing, which is people are asking the question, you know, if I'm being charged essentially per subscription, doesn't that like imply that there's sort of a cost per subscription and then if my subscriptions are quite low or quite high, like that makes a difference, right? So that's something we need to think about. Like if, if somebody is charging $3 for 1,000 customers, that's very different than someone who's charging $2,000 per month for 50. And so that's something we're gonna have to grapple with. At first, we thought about having an Overages type model for subscriptions where you get 100 subscriptions included, and then maybe we charge 50 cents per subscription. And we backed off of that because of that feedback. And so that's going to be something we continue to look at and decide whether it's the, the right metric and the right model.

Yeah. Just to add onto that, let's say you're sitting at like, you know, 80 or 90 subscriptions, um, and you're paying $200 a month as part of our growth plan. Um, you're kind of at the upper end of our growth. And so what happens when you go to 300 subscriptions? Well, in the growth plan at $200 a month with, let's say, 90 subscriptions, right, you're paying about $2.20 a subscription. And if your ACV on a subscription is thousands of dollars a year, probably doesn't strike you as a big deal, right? But what if your ACV subscription is $5 a month and you're looking at paying schematic $220 a month on a $5 a month ACV subscription, that feels really prohibitive, maybe even regressive. So that's sort of what I think Gio is talking about, the tension with this price metric that is not something that we can escape. But I think the principle behind this for us is that as you scale, our pricing per subscription decreases. So for example, if you're paying us $200 a month for your first 100 subs, you might then pay us an additional $25 a month per every 500 new subscriptions up to 1,000 because we do volume-based bands. And so if you end up at $300 a month for 1,000 subscriptions, you know, you're paying us, you what, something like $0.40 a subscription. So again, what, what we're trying to do with this pricing is not at all be sort of aggressive or punitive, but instead, as you scale, we scale, but in a way that, um, actually gets better for you over time. I think the, the kind of the other note I just want to add on the add-on is, you know, the way we always think about add-ons is like an add-on is a really good tool to use when you have a subset of users who are going to be power users of a specific set of functionality. And that's sort of what we learned is that we have a subset of our customers who are always using overrides, who are always using webhooks and alerts, who are always doing sort of needing a lot more from us in the context of like data export and things like that. And these are, these are features that help our customers, help those customers actually make money. There are also features that only some customers need. And so we wanted to basically give people the choice. If you feel like you've got these advanced needs, buy this Teams add-on. It is high value. It will make you money. It'll pay for itself. And if you're not at that stage yet, you don't have those needs, don't worry about it. You can, you can buy it when you get there.

Nice.

Okay, um, last, last couple minutes here. Anything else we want to talk about here on this pricing update? I think we'll probably do a similar episode in another 3 months once we get to the next iteration. Something we generally believe is crucial is continuously iterating as our product matures. But anything else we want to talk about on this, on this specific iteration?

I think you said it, that's the name of the game. We don't believe, having seen a lot of pricing out there and obviously worked with a lot of customers on their pricing. Like, we don't think there's such a thing as the perfect pricing. There's just such a thing as a good pricing practice where you're consistently looking at it, evolving, listening, and you need the flexibility to do that. So like you said, we'll keep looking at this. We'll probably make another iteration soon.

Awesome.

All right guys, talk to you soon. Thanks for listening.