Stigg: Infrastructure for pricing models with Anton Zagrebelny

I even thought, Like my specific domain expertise was work building trading platforms, like for stock brokers and, and everything around, you know, the tooling that requires to manage do trading platforms for also institutional investors and also for retail, retail investors. So I kinda categorize myself as an expert in trading platforms. And then like, there's was a. Change like from my end when I decided I wanna start having like being my own my own boss.

And then I started open the software company and then hired a bunch of people and we made like kind of a lot of different projects and product, built a lot of products for like a variety of customers with was small startups, both big enterprises. And then I was like exposed to many different industries and. You know, many different kind of type of products. And afterwards I had the opportunity to join New Relic as a senior software engineer.

And this is actually where I met my co-founder do and together we co-founded Stig. So, yeah, it was a a very interesting experience for me also working at like a big enterprise. Working on a new product that new Relic has acquired a startup company here in Israel. And then we help them together to build this new type of product, which called Lops. This is like a product line that involves everything that is related to machine learning, monitoring and observability around these areas.

So it was very interesting to. . Yeah, so that's, that's, that's a brief history.

What does that look like?

It includes also the product itself, also different types of billing systems, also different types of CRMs, and we like basically tie all those together. But if I need to say like, You know, what, what do you do, do best? Because that sounds like a little bit of vague. So basically, STIG is a, at it core, at at its core is an entitlement management system, which I think this is the foundation for any

flexible or agile pricing, packaging tooling or . And to bring our software this is our centerpiece. And from there we evolved. Different areas such as usage based pricing and pricing, experimentation, and a testing. And on top of that is basically what allows us to do that is basically this entitlement piece. For, let's say from the the companies that we work with are basically the ones. or they want to try like the small segments, or they want to try out new price.

Like they wanna roll the first pricing okay. For a software product. So they, they don't know where to start. So they usually reach out to us and try to figure out like what's the base based way to do that? What, what's the best pricing strategy for their specific product or industry. Then we try to help out give them some little advice or connect them to other pricing experts that might help a little bit.

Information can help them do something more intelligent rather than try to guess that what's the best pricing for them. And the second, second type I think of of customers that work with us are the ones who already has some, like a, already has some pricing strategy in place, and then after like few years of running with that, they figure out that they wanna change that because.

You know there's usually, there's a saying that if you don't iterate or change your pricing strategy over time, you basically living money on the floor. That's, and that's natural because usually the companies when they start, you know, where their initial pricing is, something that they decide on very on, very early on. And then, And they just wanna build a user base. They just wanna get traction.

But after a year or two and they start to evolve and they start to grow and they want to increase revenue, I think the first thing they thinking of, okay, let's change our pricing. Cause that pricing is obsolete, it's legacy. We need to update it accordingly. We build so much for those two or three, four years and it's, it's insane if we price it the same, you know, the same in the same way we did when we just started.

. So this is, I think that's that's the tipping point where they start looking for like, how we do that, how we plan that, how, which tools are out there that can help us to do this type of change. So I guess that's, that's also the point where we where we can help them and enable enable them to do these changes without, you know, rebuilding their own infrastructure all over. And also prevent them from doing that again in the future.

And how pricing strategies work. So this is something that's definitely very interesting to me. Man, I have a lot of questions from here. So, l let's talk a little bit about companies trying to figure out their initial pricing strategy. I, I feel like, and a part of that is just for many companies who I'd imagined, well actually let's even start a step further back. So does Stig primarily work with subscription-based pricing, or do you do like one-off purchases and things like that as well?

And we also, some, this is also something that we support. But we, like from technical standpoint we don't see ourself as a billing system. Basically, we sit like between your product and the billing system. It means that the configuration. Of how your pricing should look like and how you wanna, how you wanna like charge your customers something that you define and stick, but the actual, the actual billing, like the actual invoicing is happens in the bearing system.

Like if you use Stripe and you decided to switch over to God knows what, and we support this kind of integration, you can do that by having, by, by doing a, a few clicks, like in our, in our No Code user interface, and then you migrate all your customers to a different billing.

. So basically I think that's because our focus is on the SaaS companies, we try, we try to bring the best like the best capabilities that suits their needs. I think we go like for the best practices that are in the SaaS industry and trying to like, consolidate all those different types of, of, you know, companies are trying to figure out what they need to do into like what are the best practices and how you should price your product based on certain.

And factors, so, so we like our pure focus is basically on SaaS companies in that area.

But then if you think about it a little longer, I think probably everyone has seen some pricing page on the internet that has a three, you know, a table with three prices on it, with a list of features below it. And even. Seems simple at first blush, but the process of building that out and even designing that interface in a way that people understand what's there and that it's clear and that you set up pricing correctly, there's a lot that goes into that.

And then it gets even like more wildly complex when you talk about things where enterprises might have a graduated pricing that gets cheaper per seat after certain tiers, or they might have usage based. That's like for all of these AI products where you're charging per API call based on tokens, right? Like the, the can be more expensive and things like that. And it gets wildly complicated from there.

And I think a lot of people don't realize that that is such an intense problem space and that, like you said, all of these companies are in their own way. You know, they consider themselves unicorns because they're trying to figure out the best way to, to provide value to people to make money. it strikes me that there's a lot to explain there from a, hey, like, STIG can help you do this perspective.

And then there's sort of the implementation step of, it sounds like you plug into lots of payment services, so maybe something like Stripe and Adian and PayPal and all these places that can take payments. And from, from jumping into your webpage and looking at you know, STIGs homepage, there's some pretty intense diagrams of plugging in and out to SDKs and widgets and all kinds of things there.

How, how do you explain, The placement of STIGs sort of integration service to, to companies looking to build, like where, what do you start with? How do you say, you know, what's your hello world for Stig look like?

All those types of different pricing model, pricing models. I think that the building blocks are quite the same, like across all those companies. As you said, there's like this token based pricing. There is this subscription based with a flat fee and there's this. Types of plans with different limits maybe, or there's a, like a one, one value metric or two value metrics.

But at the baseline, if you take all that and try to find a common denominator between those two, you can actually build some, like an intelligent pro platform that is still flexible enough and build using those building and using those building blocks. You can model all those. Pricing models and supported end to end. So regarding your question of like how this Hello World application looks like.

So basically Stig is, as I said before, is, is basically allows you to, you know roll out pricing changes faster if, if it was a very complex and. Complicated product with many integration points and, and you have to invest a lot of time in order to get value at stake. Wouldn't work, that wouldn't like be our core value that we provide to our customers. So basically from day zero focus was how you reduce the integration time, how you make things more simple.

What, what is the immediate value that you can get the developer can get by using Stick. Like what we, what we're trying to, what pain do we, you know we sooth. So basically, I think that the whole low world example would be like the first thing that a developer usually starts work on when he gets this pricing test. Like usually there's a ticket in your trailer or Jira. That's, we need to roll out our pricing. Let's start with the pricing page.

So basically , you know, let's not wire they that behind the scenes. Let's just put our pricing out there and see how the, how our customers will react to that. And, and this is basically what our like things that we gave give out out of the box are there's pricing plan widgets that you can an embedable widgets that can just simply drag and drop into your website, into your applic.

and based on the pricing configuration and Stig, you get this magically pricing plans, everything dynamic according to your to the configuration that you set according to pricing strategy and Stig. And it's already functional. You already got the value. You didn't have to build it, you didn't have to break your head. How I model this, you know, different plans, how I style them, configure them, everything. There's no code solution in stick that allows you even to style and theme this type of.

So that's the, the hello world that that I think that's the, that's the most simple thing that can get from stag, like the most straightforward one. And once you are ready and you wanna, you know, switch gears, then get, take it to the next level. And you wanna have pays inside your application. You wanna have a customer portal in the new application so customers can upgrade and downgrade their plans in self. So, This is where it gets interesting.

We have widgets also for those pieces, but we also need to make it effective, we need to do this kind of backend integration with Stig, where you need to, first of all start reporting usage to Stig. Whenever a customer adds a seeds, remove the seed. If you want to have that enforced by Stig, that is something that is also required to do. And then later on you can. You know, start feature gating, start limiting those based on the usage and start billing on certain metrics if you choose to.

And everything will be no code since that point. So basically, once you integrate the stick one, you won't have to do this integrations. So over again, whenever you choose to or decide to change your pricing model.

Phil, my, my co-host and co-founder here has authored a few books that we sell on the site and right now, if you went to buy books on the site, we sell them through Amazon and through Lean Pub and through a couple of different places. Shopify is, is one of our providers and we have few times thought about trying to make it so that it's easier for us to manage all of those things centrally and playing around.

selling digital products for a set price or doing something like our own Patreon ish thing for won't hate. And the thought of trying that out and having it not work and having to rip it out or having to change it or something like that, is essentially as the, the, you know, Two to three person, developer team for the site is an intense amount of work. And essentially one of those things that just becomes a non-starter from the beginning.

And if you think about, you know, maybe, I don't know let's say Anton, you and I were building a dating app, right? And we wanted to charge 10 bucks a month and we decided next month that we needed to split it out to three plans. That's 10 bucks a month, 20 bucks a month, and 50 bucks a month. It's so much work. You have to plum that in through every part of your application.

, there's a lot of thought to, into gating off features and functionalities and all of that requires code changes, or at least as it sounds like all of that did require code changes on some level. so it's, it's an a very interesting i, I guess value proposition for people building

It started like becoming a very not straightforward engineering problem because usually when people see like you know, you, you, you wanna start pricing, you think of, okay, I'll just go to Stripe, I'll drop in their their APIs, I'm gonna use their embedded checkout hosted page, and then everything is simple and I'm done.

But it's not that accurately true, but, while Tribe does the, handles the payments, and handle the handles, the checkout experience, there's a, a lot of uncovered area there, which is around provisioning. Like provisioning is what happens after the checkout. How like, okay, so our customer has purchased this problem for $10 a month, and right now we need to provisioning access to the feature. He's paying for it. And this is where things started to get complicated.

He started looking for, okay, how I need to listen to this WebBook from Stripe. I need to understand the subscription lifecycle, the subscription started renewed, canceled, all this type of events. You need to handle that on your backend. And how do you reflect that in, in the app itself? You know, like the subscription ended, we downgrade the user to the flip plan. We block evoke all access to the, to all the features in the application, this type of decision. Are very, are very fluid.

They change over time. Like it's a, it's a business decision. Business decisions change and it's when developers and engineers start building this type of solutions, they, they have this like tunnel vision on what you need right now. Like the, the management told me this is our pricing. And they know, like in their standpoint of point of view, it's like this never gonna change and it's just gonna.

I just wanna get over with it and I want to continue on my life and building more interesting features and, you know, wiring up all this building side into my application. And this is actually the first the first event when you start gathering and aggregating this. Technical depth regarding those, you know, pricing and packaging stuff inside your application. And then this depth hinders you from, or at least cost you a lot once you try to, you know, to ang it later on.

So this is something that engineers don't see at the first, like when they first approach this problem. So this, that's why we at stake, we're trying to educate and to trying to, you know talk about this, like how our approach, the entitlement approach simplifies things in that, in those areas that once you integrate with start con the concept of entitlement, similar to feature flex, like there's you, you start working in it. It's very natural to you once you see the value of using that.

but I think the other interesting side of this too is that product creators, the, the sort of product side of. Doesn't often have a full understanding of the amount of work engineers need to do to rework something fundamentally like that. And at the same time, engineers often don't understand that product. People need to be able to make sweeping, iterative changes to, to keep the product alive as well. So it's an interesting challenge for sure.

I wanna shift gears a little bit understanding that the, what the product does and what it is and who you're talking to. Let's talk a little bit about how it's built, right? So your, your CTO. Dig. How is the platform built? What tools do you use? What li languages and libraries do you support?

Are built specifically to handle the entitlement's problem, which, which means, which me directs me to this conversation. What is the entitlement's problem? And generally speaking of what entitlements are. So basically if you think of entitlements, it's something related to permissions in some way. Okay. So basically permissions are.

Like definitions of what a user can do according to its role or its certain set of attributes and entitlements, on the other hand, are set of permissions that a customer is assigned to that can decide what, which features in the application. The customer subscribe to, like part of this license model, if you want to compare that and use those terms, which is a little bit outdated terms, but I think it's like a trend that's coming, coming back again. But So, yeah, so these are type of permissions.

There need to be evaluated quickly and very often because every time the user interacts with your application, they probably, you need to do this type of check if the user subscribe according to its plan to use this feature. So the variation itself, it has to be like super fast, low latency, like and every.

every bump in doing this decision in like in the process of making this decision can affect the, the overall like experience, user experience, and the latency of the, your API product or whatever you're building. So like our focus is basically allowing building the best as the case we can that evaluates with almost zero latency, those entitle checks, and you can safely use them within your product without.

Even breaking or thinking of how you gonna, you know, what's the best way of implementing, then just do it, be a drop in and that's it. The problem is solved. So there's a lot of logic being going on in there, which, like, there's several factors like, you know caching and prefetching data or real time updates of this environment whenever they change this type of, you know, problems is something that is the case.

And regarding our api, so basically there's a, that's as I mentioned, our main API is a Graph Q based api, which serves we, we call it a management api basically because it's usually the the API that our, like user interface is using our application. And we have another set of APIs, which we call them the Edge APIs. And those APIs are basically a build. On, we're using as a lot of AWS services as we can.

So the Edge API leverages the cloud front, lambda edge type of distribution, which means our code executed at the closest region. To the user that invokes that api. And we also using dynamo DB's Global tables feature, which means that all data is replicated across multiple regions so that those lamb, that functions run on the edge can access their data closest to them, basically from the same region that they're rely on. And that's how we.

The minimum latency we can globally regarding to all this mission critical data, which involves the usage, the entitlements and we also gained the uptime guarantee of AWS for the services. So we, so cus our customers can feel much more safer depending, you know, on the, on the giants like aw. To handle this type of failures if there, if there were any failures in it,

How many engineers do you have working on that?

Then the next day they build this dk. Next day they work on the Edge API. And like this this like multi, you know, multifunctional team can Work much more efficient than having this type of, you know, usually like separation between that there's a front end engineer, a back engineer, and then they, it's hard to, you know coordinate the work together with along them. So basically having a team of full stacks for a startup at the early stage is a very big advantage.

I can, you know, there's a lot, there are probably some companies that are near your you know, in those areas or outside this area. Never. , like, how do you stand out? I think that the way things stand out is basically focusing on the developer experience in a deaf persona and trying to reduce the work that those engineers that are tasked to do to work on the pricing for a company. Trying to retake the, the, as much work as we can from them to us and to enable them to move faster.

If it's improving our tools, improving APIs supporting more different problems and different use cases that they face, I think that's, that, that that's the thing that we truly believe will make a difference. And in general, make our customers more happy. So yeah.

And there's a full description in our careers page in our website and state I. So so anyone who's interested can jump in and read more about it.

So this is something, a topic that we didn't talk before, but it's also very interesting. So when we tried and, you know, started playing with our own pricing, I think that what we felt comfortable most is that because we are using stick, we don't have to. Commit to the pricing. know, we can always make the op made the decision to change it, and it'll not cost us any engineering effort in this, in this process.

So so like if you ask a company like why you don't change your pricing often, they usually tell you that it's because it's hard. We don't change it because it's hard and over how like we. Talk with a bunch of different teams and get one on board, and then talk with the engineering and run those, all these changes. And then that's why they do it like once a year with the best.

but if you, if you break that paradigm and start using the flexible infrastructure that allows you to do these changes more often. , then you won't have this problem. You can change pricing twice, three times a week, So yeah, so that's, that's basically how we also leverage in Stig inside Stig.

Like it's, it's an in available, so basically even if you deploy something and it doesn't work, what you do, you, you roll, you, you have the ability to roll back, or at least you, you add disability like in your c i CD, orchestrations or what whatsoever. Without it, you're, You're helpless. You need to, to, you know, to fix it and re-deploy it. And, and this process takes much more time than the, if you had the ability to just roll back your change.

So stake in some way is, is, is that rollback? Like this is, we grant give you the ability to, to regret

This was Anton from Stig there'll be a link in the show notes to both the, the product page as well as jobs for Stig and contact information for Anton. Anton, thanks so much for hanging out. I really appreciate it.