Monetizing SaaS: Episode 33 with Aubrey Rhodes, Ex-Calendly, Mailchimp, Blue Bottle, Stitch Fix

Aubrey, thank you so much for being on the podcast. It's been a pleasure to get to know you over the last 18 months or so. You've, you've been an incredible thought partner to Schematic, and I'm grateful to you for being a part of this conversation today. You've been an engineer, you've been an engineering leader, you've worked for some amazing companies like Blue Bottle, Mailchimp, Brightwell, Stitch Fix, Calendly, and you're currently the CTO at a startup called Workful. Tell us how you got to now. How did we get here? What's your professional journey in your words?

Yeah, yeah, really excited to be here. It's been really cool to see what you've done with Schematic and kind of watch it grow. So I started in engineering at Georgia Tech. I'm from Georgia. I've always kind of lived here. And after school, got into a consulting company, Big Nerd Ranch, here in Atlanta and got to see some different startups and really enjoyed working with small companies and building out products, trying to take it to market. And so got a lot of exposure there and then worked in different startups and scaleups around Atlanta and some other places. But I've been lucky in my career that I've gotten to move around a fair amount and see kind of different practices in different companies. And I think that was always one thing that was cool about the Atlanta tech scene was there were just a lot of different companies, but you generally knew someone at each one and you could talk to them about how they were building the things. And so got a lot of cool contacts and experience of just hearing how different companies grew and the practices that they had. And yeah, I got into engineering leadership, really enjoyed coaching and working with teams and kind of scaling out impact that way. And so yeah, worked through Calendly, managed their kind of billing and monetization and growth program there. And then for the last few years have worked with a much smaller company, Workful. Workful, who I've been the CTO of and kind of helping get their product and engineering all managed.

It's a great story. And I want to go deep on a lot of what you've learned around monetization and billing. But before we go there, so you were at Calendly for roughly 3 years, 4 years, and then you joined Workful. What, what led to you wanting to go from, you know, a company like Calendly, which I imagine at the time was several hundred people to really early stage again?

Yeah, so I think two big things. First, I've always enjoyed working in the earlier stages of companies. Um, I have been lucky to watch a couple different companies grow really quickly. So Mailchimp, while I was there, went from, um, I think 200 to 700 employees, like was growing really quickly. Calendly was going through a similar phase, and that time is a lot of fun, but I've always just kind of enjoyed the atmosphere of working in smaller companies, getting to wear different hats, knowing everyone pretty closely. So there was that partially, and then there was also kind of a personal thing of moving home to Augusta. So I'm from here originally. We have a young family and wanted to be close to the rest of our family. And Workful is a local business here. So we're all headquartered here for the most part, although the employees are in Augusta. And so it kind of feels like going back in time seeing the tech scene in Atlanta grow in 2005 and being able to have an impact there. Augusta is much smaller. There's, you know, much less of a tech influence here. So being able to have kind of an impact just locally on a growing company and having opportunity to pull people into the industry that way too has been really cool.

Yeah, very cool. Well, tell us about, you know, where your time is spent these days at Workflowy. You're the CTO. So where is your energy generally flowing? How do you kind of compartmentalize where you spend your time at this point?

Yeah, so we're much smaller. The engineering team is me and another full-time engineer. So we're both, you know, knee-deep in code, focused on solving problems for our users. So day to day, that might be helping with a specific payroll issue or, you know, something that's kind of gotten stuck in the process, or developing new features and trying to make that process easier. And then, you know, from a higher level, making sure our back office all works, all of the reporting makes sense, we have all the information we need to make decisions, and keeping our other engineer directed and happy and making sure that he knows what he needs to do and also is happy in his career. So all the hats all the time.

You've built and operated on monetization, on pricing, on packaging, and sort of the systems architecture that governs monetization. I imagine now at a variety of companies, but certainly you went very, very deep for a very long time at Calendly, which had a ton of complexity and hyperscale. Um, I'd love to go deep into what you've learned from that experience, and maybe as a, as a jumping off point, can you tell us a little bit about the role at Calendly, what you were doing, what the team looked like, what the charter of the team was.

Sure. So when I joined Calendly, I think we were about 50 people and it was profitable, I think, you know, in the double-digit millions of revenue already, but had gotten there just solely through Stripe billing and kind of the— if you've ever done a project on Stripe, like just the first project of getting it set up, that's what they had. And they were starting to run into issues of they wanted to support more payment providers. So they were interested in supporting PayPal for Europe. There were starting to be more constraints that were coming in. They were large enough that states and municipalities cared about sales tax for them. That was a big project for us was to start to support sales tax. And the product had grown enough that the initial pricing and packaging no longer really made sense. As we were adding new features, we'd have to decide decide where it went. And the kind of simple pricing model that they had wasn't supporting the new features that were being added in. So it was a project of kind of supporting those things and then also moving from Stripe Billing to Chargebee because at the time it supported a lot more of what we needed to that Stripe Billing hadn't quite caught up to. It was before they had rolled out their sales tax offering, I think. Some of their billing and kind of back office stuff wasn't as fully featured as Chargebee at the time. So it was a project of moving all of the billing over to Chargebee. Our integration with Stripe billing had to be rewritten into Chargebee and kind of rethinking all of our processes there. And then eventually kind of redoing our pricing and packaging completely from the old prices and plans into a new one that would support the company as they transition from kind of purely PLG, you know, self-service signup to having that and the sales team and kind of going after larger customers. So we started with, I think, me and a product manager and 3 engineers and grew over time to be 3 different teams of 5 engineers focused on kind of the billing infrastructure, the checkout and kind of billing experience within the app and then started to do more growth of how do we tie together kind of marketing into onboarding and checkout and how all of that flows together.

So a team of just a few people to a team of nearly 15, 20 people over the course of a couple of years.

Yep, exactly.

Yeah. I mean, I think one of the things that's so interesting about that story is it feels like, it feels like the story of companies that are successful in that you often start with a simple product with simple pricing and packaging. And then over time, if you're successful, life gets more complicated because you launch more products, you layer on new go-to-market motions, and you might even evolve like the billing model and layer on kind of different ways to bill customers. And that almost inevitably creates a lot of complexity for product and engineering. Do you— you know, one thing that I've kind of been asking myself a lot over the last year is, is there a pattern or a standard for product and engineering leaders to turn to in the context of that complexity? Or are product and engineering leaders largely having to figure it out themselves and reinvent the wheel?

I think that in, in most companies that I've been at, it's been, uh, figuring it out ourselves, but we end up kind of coming to a similar conclusion. So a lot of the pain with these transitions are the design of billing integrations for most of these SaaS companies are really, really simple and aren't expecting, or they aren't too flexible in how they can change. So I think at Workful, we've adopted kind of a legacy system where the state of the organization is tied directly to are they subscribed or are they not? And that's really simple to build out. And I think as a starting place, it makes sense for most people. But when you get to, okay, now we've got a second plan, or we want to introduce an add-on, it's really hard to figure out how to evolve that into a new thing. And then you're stuck with these conversations of, yes, we would love to have the add-on for, you know, extra support SLA. But we're going to have to redo our entire billing system for that. And so the prioritization becomes really tough because you've always, you've got all of this baggage of redoing your full billing system whenever you're just trying to add a feature. So you either figure out really kind of hacky solutions of, oh, well, we'll just have the support team invoice them the extra amount. And then you've got all the kind of organizational complexity and debt that comes along with that. Or you just don't do those things that would help your customers and help you bring on more revenue because you've got this debt of we have this inflexible billing system. So I think realizing that doing as much as you can earlier to get engineering out of being a bottleneck for price changes or packaging changes, you're inevitably going to get to that point. Like, as a SaaS company who's charging a subscription, your users expect you to add more functionality as time goes on. You're going to want to charge for that. And so if you're successful as a company, you will inevitably need to change your pricing and packaging. So you need to realize that from the start, because otherwise you have this drag all the time of we have to redo our billing system and just talking through, you know, the cost associated with that.

Yeah, it's the one thing that we know is true is you're going to change pricing and packaging if you're successful. Like we may not know anything else, but we know that.

So, yep, exactly.

So help— maybe, maybe if we can kind of— I want to see if we can kind of help paint a picture for other product and engineering leaders about like what typical B2B SaaS monetization architecture often ends up looking like, and then see if we could paint a picture of, well, what would more flexible look like? And maybe we could kind of think about, you know, how we might articulate different services that make up a more flexible architecture. Before we do that, maybe could you just explain for a minute, you said a lot of the complexity comes down to the way we've integrated with billing systems early on and debt. We incur debt over time based on that initial implementation. 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 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 of, 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 entitlement. 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 either into a separate service or into something like Stripe billing or something else. 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, 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. Typically what this kind of looks like is they're basically hard coding an entitlement into the application and tying it very closely to an ID in the billing system, right?

Yep, exactly.

And you know, what you have learned is that often creates a bunch of challenges over time to kind of support flexibility. Um, and 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, 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 gives you a lot of flexibility there as to changing really quickly your pricing model and being able to iterate on it. And then down the road, it opens the door to the pricing and packaging that's inevitably going to change because of your growth.

What is— just because we're on this track for a second, we're talking about entitlements. How prevalent do you think this term entitlements is? Do developers kind of understand what entitlements are intuitively? Are there other terms that people use, like permissioning? How do you think about that?

I think so. Entitlements isn't really gonna be a common term with most developers unless they've worked really closely on billing systems. I'd be surprised for them to kind of jump to that term. But feature flagging is a pretty common idea, kind of app development. Just the idea of having a true or false flag that you can turn on for a user to say if they have access to something or not. So yeah, that concept is more prevalent, but more used in the kind of process of rolling out new features. So a lot of teams will build something, roll out the code, but have it turned off and then turn it on for specific users, then everyone over time. But that's really no different of a concept or a service than doing billing entitlements.

Makes sense. You know, I feel like I've learned you know, over the last couple of years that companies often approach entitlements in a variety of ways, each with their own trade-offs. I think if I were to try to capture sort of what I commonly see, it's either I've done what you described, which is I hardcoded the entitlement, and this is sort of quick and dirty. A lot of companies do it at the early stage, but it racks up a bunch of technical debt. Other companies might use like their auth tool or maybe like an authorization service for entitlements. And it seems like this is good for companies that have really complex RBAC and user permissions, but maybe kind of it doesn't empower the business to go control monetization when it's done that way. There are entitlements that are sort of managed in the billing system, you know, and, um, like Stripe is launching an entitlement service. It doesn't actually integrate with the code, but it's, it's sort of a hook that you could use. And this seems like it also might lend itself to commercial and technical debt over time. And then there's feature flags as entitlements, but many existing feature flag tools don't have like an out-of-the-box concept for entitlements. Developers just use the feature flag as an entitlement flag, and it often requires like a bunch of building from the flag into the billing system or the CRM. And so I want to stop there and ask you, is that, is that probably a good encapsulation of what companies are often doing as it relates to entitlements, or have I missed something really important?

No, I think that is— I think the authorization one is a good one to bring up because it feels a lot like authorization is something the user is allowed to do. But a lot of times, it's kind of organization-level authorization. So if you have kind of a setup where you have a customer with multiple seats, authorization a lot of times will deal with this user as an admin, this user as a viewer. So, you know, for this document, what are they allowed to do? And the billing entitlements don't always work so well in that, that pattern, because you're really thinking about the organization there. So it's it gets really odd to try and design those in a lot of the common authorization languages that you use. So it ends up being kind of a hack there if you do it. Yeah, with feature flags, you end up having to hack together some way to keep the state correct between the billing service and your feature flag system, or you're just completely tying together your app and the billing service, which doesn't work.

Yeah, interesting. So let's go back to systems architecture. So in your standard B2B enterprise software company that has achieved product market fit, they're doing $10, $20, $70 million of ARR. What do you presume to be the key systems that are governing and or operating on monetization and pricing and packaging? Yeah.

So I think the— you'll have the application, some type of entitlement service to kind of drive what are they allowed to do based off of the billing. And then usually externally, but sometimes internally, some kind of billing service. So the thing that looks at the state of the user's account and decides when to charge them and kind of reflects out, hey, they're delinquent or they've canceled. There's some UI associated with that. So checkout is the common one, but also the ability to upgrade, downgrade, add users. Having that be kind of separate from the main application can be valuable because you're not having to spend engineering, like application engineer time on those things. And then there's kind of the back office tooling as well. So support will need to be able to do refunds, discounts, all of that. They'll need to be able to affect the states of the billing service and then all of the reporting that's needed. So a way to kind of dump data out of the billing service and either tie that into other reports or just use that to understand kind of the basic accounting needs of a business.

What's the role of the CRM or some of the sales stack in this architecture?

So it depends on the business at that stage. Even if they say they're fully PLG, they'll have some kind of sales team and care about that. So being able to make sure that that data is consistent between the billing service and the CRM is really important. And then kind of the more sophisticated your sales team is, or the more reliant you are on sales, the more integrated your billing and CRM will be. So for a fully sales-led product, you kind of expect to be able to build a quote out in the CRM and then push it to the billing system. So that means there's kind of syncing between the product catalog between those two services. Yeah, and then tying together, you know, the reflecting back the billing state into the CRM to be able to say, hey, you know, these are the companies or customers that you have that are in good standing, these have gone delinquent and you need to reach out or however that is, that data gets reflected back in there as well.

Yeah. That's super interesting. And I think like one of the things that I've started to try to like create as a mental model is, hey, I mean, let's say you're a $50 million company. You probably have product-led growth. You probably have a direct sales group. Maybe you've got channel, you know, who knows? But, you know, as it relates to what are the systems operating on pricing and packaging, what I think I'm often seeing is you've got sort of the sales source of truth, which is either the CRM or some CPQ product. And usually the CPQ is like Salesforce CPQ. So it's like really your CRM. Uh, and then you've got your billing system and people talk about billing in a variety of ways, but like, I think that there are kind of two ideas here. One is you've got subscription management and you've got invoicing and then you've got your application. And so many companies just have a bunch of homegrown glue code between these systems, which contribute to the commercial debt. And so maybe the exercise I'd like to see if you and I could explore is if we were to come up with a set of services that were they to exist in an engineering org, engineering could kind of fully liberate themselves from having to support this problem. What would those services be? And you've already mentioned entitlements. You've already mentioned the idea of a product catalog. Can you talk about the services that you think are really important? And maybe you could kind of tell us that through the story of Calendly, like where were you when you began? What services were there, were not there? Where were you when you ended? What services were there and had become really crucial?

Yeah, I think from the application standpoint, the two things that you want are the entitlement service. So being able to see what the user is allowed to do based on their billing state. And then kind of the subscription management component of it. So being able to have a link for them to go to, to check out or something to embed into your site for subscription management. Sorry.

No, no, no. And maybe just to kind of riff, right? Like, we've been thinking about this hard because so many times I've run into CTOs who say, I feel like I'm reinventing the wheel and there's no architectural pattern to turn to. And so it's the question that's most interesting to me right now is, well, if you were to create a pattern, what would that pattern consist of? Is it an entitlement service, a subscription service? Do you have to have other services like metering or like a product catalog or flags or like some centralized, you know, kind of customer state or company profile? Are there 3 other services on top of all those? Like, that's, that's sort of like the drive here is to understand what a pattern could look like that could be really useful to basically every company.

Yeah. And so at Calendly, we started with just the idea of an entitlement service and everything else was kind of integrated into the rest of the application. And over time, we started to pull more and more out. So I think the next thing was really just having a separate billing service that lived in between entitlements. And for us, it was Chargebee, but whatever our subscription provider was, so that we could kind of abstract that away from the rest of the organization. And that was where kind of the idea of the product catalog lives. So mapping the subscription state to whatever the entitlements were. We hadn't gotten to a place with our pricing and packaging where we needed to do metering it, but that was something that we talked about that would be kind of a separate service. And that one, I think, is easy to forget that it can happen out of band. You can report that metering a day later or a month later, you know, really just in time for it to show up on that invoice. Assuming you don't need to be too strict with your enforcement of it. So if someone goes over their quota, if you're okay with them not getting turned off for a little while, that can be something that happens out of band and is totally abstracted away from the rest of the application. And then the idea of a source of truth for customers is a tough one because it gets spread around between between kind of auth services and reporting. I think a really mature organization will pull that out and have a separate service that's kind of identity and auth and authorization, authentication and authorization kind of all tied together. I think that's tough to do though, because it ties into so many other parts of the application.

That's super interesting. You know, one thing that we've talked a little bit about is entitlements, and there's sort of varying degrees of understanding about entitlements. You know, if you've worked on entitlements as an engineer, you get it. If you've never worked on— or excuse me, if you worked on billing, you get entitlements. If you haven't, maybe you don't know what it means. Do you think product catalog as a concept falls into a similar vein, like where you like actually haven't really thought about product catalog in SaaS unless you've worked on billing? Or would you say that's not true?

I think you end up coming at it from a few different directions. So billing is definitely one where you think about a product catalog, but analytics, like user analytics ends up being kind of a similar thing as well. Because you're trying to answer questions of like, has this user activated into this particular feature or not? And so you end up having all of these, like various Google Docs and Canvas and everything where you have definitions around this particular part of the application maps to this feature, it maps to these kind of events in the application. And eventually you have to kind of standardize that across the application. So it's something where you kind of come at it from different angles and being really strict and organized about it from the start can be really, really helpful, but most places don't start from there. You kind of fumble your way into having a more defined sense of that.

Yeah, it's super interesting. You know, I've, I've talked to other entrepreneurs who are thinking a lot about this space who have, I think, concluded that the root cause of all of the complexity around monetization is multiple product catalogs living in multiple sources of truth. The idea that there is a product catalog in the CRM or the CPQ, there's a product catalog in the billing system, and there may be even a product catalog or some sort of version of a product catalog in the application. Monetization. And I'm curious to know your reaction to that argument compared to the argument that much of the complexity stems back to what you cited earlier, which is the way you deal with entitlements early on, the degree to which you couple business logic in your application. If you took those two arguments side by side and compared them as their contribution to complexity around monetization, how would you compare and contrast?

I think the— product catalog issue is probably more of a kind of a root cause and entitlements can be kind of a symptom of that. Because ultimately, with entitlements, the things you're asking whether or not the user is entitled to are the items in that product catalog in a perfect world. So if you don't have that idea of like an entitlement service in your application, you're just you've got that logic somewhere else of these are the behaviors allowed based off of the state of the subscription.

So if that's true, if that is the root cause that gets a lot of companies into very expensive problems, and let's see if we could do two things. People get into these problems that they call tech debt or commercial debt or billing debt. Like, can we define that and put a little bit of like parameters around that? Like, What does that mean and why is it a problem? And then I want to talk about the product catalog, if that is the root source of the complexity.

Yeah, I think ultimately what people mean when they're talking about technical debt is opportunity cost for the business that's incurred by needed engineering work. So having engineers be the bottleneck for opportunities. So, you know, if it takes your engineers 6 months to do a price change, that's a big opportunity cost for you. And that's kind of what that technical debt is. So with the lack of kind of having a product catalog, that a lot of times that'll come out as we've introduced this new feature, we want to figure out how to monetize it. Now there's 5 different systems that kind of act as an authority on this. So we have to go and do the work 5 different times, as opposed to, you know, having it in one central place that they all rely on. And then you're not making decisions based off of what's best for your users. It's is it worth the cost of doing this 5 different times? Which, you know, is a lot of times it's going to make you move a lot more slowly, not just because the work takes longer, but because you're having to make such a stronger case of, hey, we need to take our engineers that are a very limited resource and focus them on this problem for the next 3 months when they could be building other things.

Okay, that's a terrific definition. I think we've established the parameters around it. Now, what is a— let's try to define product catalog. If multiple product catalogs living in different places becomes the root cause of the debt, what is a product catalog? How should an engineering leader think about it? And is the way an engineering leader should think about it the same as the way maybe a product leader or CEO should think about it?

They're definitely related, but from a technical standpoint, it's a list of things that the user is allowed to do. So, you know, things that should be turned on or off in the application, and almost kind of a flag for that. From a business standpoint, it's more related to like jobs that need to be done for the user. What are they paying for? What's the value they get out of it? Is your application being tailored to the customer specifically and what they need? And does it line up with the value proposition for your subscription? But they're interrelated in that, you know, what the application is actually doing needs to line up with that idea of what the user needs.

So today, many companies will effectively house their product catalog in their CRM. For instance, if, you know, many companies will use the concept in Salesforce of like products and price books. It's effectively a product catalog, but they'll also end up housing their product catalog in their billing tool or their subscription management tool. How does this problem get solved if you've already right there, if you've already got two distinct product catalogs, one in the source of truth for the CRO, one in the source of truth for the CFO? And we haven't even touched product yet.

Yeah, so either having a common definition or choosing one of those as kind of the authority and pushing it into the other system would solve that issue. I think an interesting thing here is that can change over time. So, you know, a product will change names or change price over time. You can't just have reporting on like the current state. Um, it needs to be, um, you know, this— they had this product this month and it was at this price, um, and then the next month it was a different price. And so that all needs to be reflected together. Uh, so the product catalog will change over time is, is I guess the point that I'm trying to make.

Yeah, it's, it's like— is a good way to define it, or another way to define it that you would agree with, it's like a unified policy file and it describes all the products, all the entitlements, and that's kind of what it does.

Yeah, I think so. And kind of with the time component of like they had purchased this product this month, so this is the price they pay and this is what they're allowed to do based off of it.

Yeah. So if we were trying to wrap some of this up for listeners, I think we've talked about entitlements in a fair amount of depth. We've talked about product catalogs. What's the advice that you would give to product and engineering leaders who maybe they're starting out and they're early-stage software companies, maybe they're starting to become scale-ups and they've, they're starting to really run into the commercial debt and the technical debt. What would you say to these folks as, as, you know, mistakes to avoid, best practices to try to implement?

I think, um, one of the important things to avoid is just feeling, uh, like your, uh, product is different. And for the most part, with SaaS applications, there's very few cases where you're going to want to do something with billing that's different than, than most other companies. So it's definitely a case where it makes sense to buy as opposed to building something just because it's so common and the cost of keeping up a bespoke system is so high because of the opportunity costs that it causes. And then the other thing is to not build in flexibility from the start. So if you're successful, which you want to be, you're going to get to a place where these things need to change. And engineers don't want to work on billing code, they want to work on cool features for their users. So as much as you can do to set yourself up in the future to not have to spend engineering time on those changes in the future, that's really valuable.

That's great. And Aubrey, this has been such a sort of masterclass in kind of talking about what companies can take away from some of the experiences that you've had. So I'm grateful. One question that I like to always end with is to get a sense of what you're curious about over the next 10 years. So when you zoom out and when you think about building software or building businesses, what are the big changes in the world that have really ignited a lot of your own interest and curiosity?

Yeah, I think one thing that I've seen from jumping around different companies is it's interesting to see employees come from other places and kind of cross-pollinate those ideas. So being able to see patterns that one company used that, you know, it's not really competitive advantage, it's just smart best practices to do things that are common between the two companies. Those ideas get spread and then eventually they get turned into products on their own, right, that other companies can kind of make use of. So going from having to negotiate, you know, a merchant agreement with Visa for your SaaS company to having something like Stripe to then having services that'll manage, you know, billing fully, that takes a lot of the complexity and work out of building SaaS companies and lets you focus specifically on what's valuable for your users to the point where now it's super reasonable to have very small companies building SaaS products. And I think it'll be interesting to see with that cost coming down, all of the things that get added into the market, just more people thinking about how to do cool things for their users and add value. Yeah, I'm really excited to see what that means over the next few years when you can think about having a 2 or 5 person company and making a big change.

I'm also really interested in that trend towards do more with less and make software just like so much more delightful to use, easy to buy. It's compelling. Where can people learn more about Workful and where can people, especially engineering and product leaders, ping you if they've got questions about billing and monetization?

Yeah, workful.com. If you're a small business who needs payroll, we would love to help you out. And then LinkedIn or I do help companies with kind of implementation for billing and monetization. And that's Aubrey at topviewlabs.com. Awesome.

Aubrey, such a pleasure. Thank you so much.

Yeah, thanks, Fynn Glover.