Fynn Glover, founder of Schematic, explains why monetization should be built into your product from the start. At Calendly, hard-coded pricing made experiments slow and risky. The fastest-growing companies ship monetization changes in days, not quarters, using decoupled entitlement engines that let engineers focus on core work while growth teams optimize revenue.
Chapters
Hello everybody, my name is Fynn Glover. I'm a founder at Schematic. I want to tell you a quick story that happened early in our journey with Schematic. I had the opportunity to speak with two people, Justin Gagnon and Aubrey Rhodes. They were leading growth engineering at a company you've probably all heard of called Calendly. How complex it was for the business to support monetization as it evolved from a simple product into multiple products with hybrid go-to-market and hybrid billing. What they found as they started working on monetization was that every entitlement had been hardcoded into the application. They found that every new pricing experiment was exceptionally risky. Uh, they found that different teams had their own version of what customers had bought, and they're effectively product catalogs for sales, product catalogs, uh, for finance, product catalog for, uh, the product and engineering team.. And so changing anything took quarters, if not longer, certainly not hours or days. One, one thing that they said that I'll never forget is a change to pricing anywhere was a change everywhere across many downstream business systems, as well as in the application itself. And so they had to take on this huge project. They had to rebuild it from the ground up with feature flags, robust entitlement engine, billing UI, usage tracking. All the things, all the components that were necessary to allow Calendly to scale into a multi-product engine that could support hybrid billing and different sales motions. I think that that story really speaks to the stakes. Um, we're living in a world where the fastest growing software and AI companies are the companies that can ship monetization changes in hours or days, not quarters or years. New products, new pricing models, new packaging. Speed here is just, it's just not a nice to have. It is the difference between capturing market share or falling behind. Most companies, however, just can't move at this pace. They're like Calendly was before Justin and Aubrey started working on it. And the reason they can't move at this pace is because in the beginning, monetization wasn't treated as a first-class citizen. It was treated as an afterthought. That led to an enormous amount of technical and commercial debt that made every change and every iteration from then on really slow and really difficult. So what happens, right? I mean, I have interviewed 200 companies over the last couple years. People spend multiple quarters just to launch new pricing. Engineers get mired in billing product project. Excuse me, engineers get mired in billing projects, often becoming billing engineers. Large companies end up with very large billing engineering teams. Companies miss out on growth opportunities. They can't use limits to drive expansion. As a small example, I spoke to a company that I'm sure everyone listening to this has heard of and probably uses last week that anticipates over 12 months to go repackage its product as a multi-product offering over 12 months. I mean, during that time, this company is going to face incredible competition and incredible innovation from its competitors around pricing and packaging. You know, what we're building at Schematic is our point of view on what a better way looks like. And I think it all comes back to what do we believe to be true? What would we want to use? What do we want for ourselves? And I want to tell you a little bit about that. I think, you know, fundamentally people think of us as a monetization platform or a billing platform. I think both of those are kind of fair and valid categorizations, but I think what, what's really important to understand about Schematic is what we believe about monetization architecture, and that is that monetization has to begin in your application. Not in your billing platform, not in Stripe, not in your quoting platform. It is all from your application that monetization begins. Okay, Fynn, what do you mean by that? Well, it is in your application that you decide how are we going to gate features? How are we going to limit usage? How are we going to showcase pricing and plan upgrades? How are we going to optimize our experience to drive adoption and then expansion? All of those are product decisions that come back to what should people have access to based on what they've purchased, what they may want to purchase. And that informs, I think, our core belief, and that is the way that you handle features and how they are packaged and sold, and the way that you handle limits and how they are packaged and sold, is the place to start. You know, ask yourself, can I gate features and enforce limits, whether they be soft or hard, without pulling developers off of core product work? If the answer to that question is yes, you're ahead of the game. If the answer is no, you need to understand why and you need to fix it. Today we have the tooling to make all of this really agile. You can gate features programmatically by plan. You can throttle limits with rules defined by business users, not your developers. Done right, your engineers can stay focused on core innovation and never have to think about billing. Ever. And your growth team can focus on optimizing revenue. Justin Gagnon, when I interviewed him 2 years ago, we ended up talking a number of times, he said it best when he came on our podcast, and that is monetization should be a first-class citizen in your product as early as humanly possible, from day one. And entitlements, what someone should have access to based on what they bought, is the best place to start. It is the place to start because it allows you to strategically decouple business logic from code so that you can move fast as your product evolves, as your go-to-market evolves, as your billing evolves. That's the architecture that we're offering and that we're constantly building toward. It's how companies that scale faster, that experiment safely, that iterate quickly, go win and compete. And one thing that I'll close with is I believe that competitiveness is a function of iteration speed, and one of the big things that we really care about at Schematic is how do we help our customers be more iterative, be faster, increase their pace. Shoot me a note if this resonates. Would love to talk to you. Would love to kind of share what we've learned about monetization, architecture, billing infrastructure, how it should all work together. Ping me anytime. Thanks.
