Mike Bifulco: Hello and welcome back to APIs you won't hate.
My name is Mike Bi Folco.
Your APIs you won't hate co-hosts talking about APIs you won't hate with some of
our friends from around the world who are building great APIs and tools for it.
I'm joined today by my new friend Anton from Stig Anton, how are you this morning?
Anton: I'm great, Mike.
How are you?
mike_bifulco: I'm doing really well.
Thanks.
It's super nice to get a chance to talk to you.
I definitely want to dig into kind of what you're working on at Stig . First
I'd like to know a little bit about you.
Okay.
So can you tell me a bit about yourself, maybe some of your background and the
things you did before coming to Stig?
Anton: Yeah, sure, of course.
I'm Anton cio, co-founder of Stig.
A little bit of background on from my end is that I'm in software engineering for.
I think more than a decade now.
Actually, like that's, that's the official number, but I think I started
programming like from a younger age.
I think my first programming book was visual Basic.
I think I got it in the fourth grade.
Mike Bifulco: That's, that's how I started too.
Anton: Yeah.
Good times.
So since then I was hooked and I, you know, really enjoyed programming
and spending a lot of time on.
. Yeah, so I've been serving also in the idf, being in tele processing corpse.
So that's how like my official career started, I think you can say that.
And since then I've been rolling into a few FinTech companies,
local companies here in Israel as a software engineer for a few years.
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.
Mike Bifulco: Yeah, sure.
Really, really fascinating.
So cool to hear that this isn't necessarily the first company you've
started, although maybe the first product company you're building.
And I, I guess all of that history of, of you know, working with startups and doing
consulting and then working at New Relic kind of brings you to where you are today.
So obviously that's building tig.
Can you tell us a little bit about Stig?
What's the audience?
What's your value proposition?
Who's, who's your user?
What does that look like?
Anton: Yeah, sure.
So basically, I'm just gonna start with what Stig is and how we see
it and what you're trying to do.
So STIG is basically an, an infrastructure product.
Okay.
That's, that means that we developing APIs and tools that allow develop.
To manage their and rollout new pricing packaging let's call constructions.
So basically what we do is we sit as a product.
We sit somewhere in the middle between like bunch of different areas.
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.
Mike Bifulco: Sure.
Yeah.
It feels like there's a whole lot that goes into even just the, the couple
of customer types you've described.
I should definitely preface this entire discussion by giving the caveat
and the I don't know, asterisk that in a past life I worked for Stripe.
I no longer work for Stripe.
I don't have ties to Stripe anymore.
But probably worth saying, just for the sake of of clarity here I've spent a
lot of my time working with and thinking about companies and, and customers and.
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?
Anton: So I think that like at stake, because we are, we are the source of truth
of how your pricing packaging looks like, like this is where we position ourself.
We basically support mo different types of pricing strategies,
like subscription is one of them.
We also support usage based pricing, and we also have this concept of you
know, enterprise pricing, which just.
There are some enterprise customers that have some custom
pricing tailored for them.
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.
Mike Bifulco: sure
Anton: so we, we kind of, we, we are a little bit limited to what
your billing system support, but.
Our vision is to support and multiple different billing systems.
So basically, once you use Stick, you're no longer vendor locked
into a single billing 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.
Mike Bifulco: Right.
Okay.
Yeah, so I, I guess for further clarification, more of the distinction
I'm, I'm looking for is you're, you're generally working with SaaS companies
and enterprise flavored companies, and not so much like e-commerce stores
that sell, I don't know, mechanical keyboards and things like that.
Right?
Anton: So basically our focus is on SaaS companies.
Mike Bifulco: Yeah.
Okay
Anton: Like the, the pain that we felt is that SaaS companies
like the existing tools are not sufficient enough for SaaS companies.
I think that because every SaaS company is considered itself as a snowflake usually,
and they have, like, I have my own vision of how I want to price my product, but
still I want to check out the competitors do that and then align to that.
But, you know, they always want to like invent something special of their own.
. 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.
Mike Bifulco: Sure.
Okay.
Yeah, I think if you haven't built a, if you haven't plugged payments,
pricing, subscriptions into a product before, I think it can be easy to think
that, like it's simple, oh, you, you just charge $39 a month or whatever, a
static price per month, and you know, that's how you work with your users.
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?
Anton: Cool.
That's a, that's a great question, Mike.
I think like the first thing that I just wanna address the the thing that
you started with is like, there are a lot of variety of, you know, different.
pricing strategies and you need to figure out how you build an, like a platform to
support all those different use cases.
But if you try to break it down like into what are the building blocks and that
that you, that a com, a software company can use in order to build their pricing.
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.
Mike Bifulco: Yeah.
Wow.
Yeah, again, I feel like that's one of those things that sounds like
you saying it sounds very simple.
Having lived through building a few different pricing strategies
for a few different products it can take quite a bit of work.
And a, a good concrete example of that for.
For APIs you won't hate.
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
Anton: I think also like the, like the, the example he gave, like, it starts very
simple, but once you, you know, trying to.
To run changes on that pricing or like, as you said, adding plans?
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.
Mike Bifulco: Yeah.
Yeah.
I think it's an interesting problem space too, because.
All of our listeners are engineers.
Most of our listeners are engineers.
I guess I shouldn't make such a broad assumption, but you know, we, we have
a lot of software developers that listen to the show and every single
one of them, I'm sure can identify with the feeling of having to go and
rebuild something that they finished and thought they were done with forever.
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?
Anton: Yeah, sure.
So so basically our current offering isn't like stickers an
API product, like from the get-go.
So basically we have craft, QL based api and we also have.
Four is the case.
I think for now we support no gs, Ruby, Python go and working more
in SD case in the near future.
But I think, like besides the APIs themselves, the API itself,
I think that the more the main the main value is actually using in SD
case because R SDKs are not just a wrapper around the api Rsdk.
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,
Mike Bifulco: Sure, yeah.
are using a lot of hardened infrastructure and a lot of, a
lot of devs will be interested in hearing about edge APIs as well.
That's something that seems to be a, a hot ticket lately too.
Didn't think to ask this before.
Do you do your APIs or your libraries support mobile use cases at the moment?
Anton: So our focus is not mobile right now.
Our focus is basically on like non-mobile SaaS companies, but that's something
that we are also starting looking at.
Mike Bifulco: Yeah.
Got it.
Yeah.
Thi this is another one of those like scars I have from, from a past life.
But mobile stuff is really complicated because a lot of it
is governed pricing and all that is governed by apple or Google.
and then even that changes depending on the country and
what features you can enable and disable are really complicated too.
But I think the The idea of entitlements is something that, you
know, is, is fairly universal there.
so support Node, ruby, Python and go at the moment.
How many engineers do you have working on that?
Anton: So currently we're a team of AI engineers.
, so yeah, everyone, like basically working like from day zero, I think at stake, my
most, my, like, my vision was to hire the best people and all, do the best engineers
I know in order to, you know, build a solid foundation that we can grow up.
So like from, even from the day one, I think all the engineers that we
are, were always full stack versatile.
They can go through, you know, build one day they build our web application.
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.
Mike Bifulco: Yeah.
Yeah.
Wow.
Sounds like a lot of very talented and very busy folks
working hard on your product.
Well, what are the things that you're thinking about next?
Like what are sort of the, the next features or problems that
you're interested in addressing?
Anton: So I think that our current focus right now is building as I
said, the best, like out for world class entitlements, infrastructure
and pricing, packaging infrastructure.
And going forward, I think that our focus will be simply improving the
dev tool set around this problem.
I think that's the most critical part.
Okay.
If you need to ask me what is your edge?
Like what, what, what, what's your focus?
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.
Mike Bifulco: Yeah, no doubt.
Are you hiring at the moment?
Anton: Yeah, actually we do we are in a position of growing and we are
looking for the first thing that we are looking, the most thing that is
in demand right now is a dev position, like looking for a dev to join us.
So basically every developer that loves.
Working with different, with APIs, with this is the case and love to
help other developers and getting feedback, feedback from other
developers on those type of tools.
This is something I think will be a, a great addition to our team.
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.
Mike Bifulco: Cool.
Yeah, that's great.
I'll make sure I put a link in the show notes here too.
So okay.
My final question is maybe a bit of a curve ball, but so you've explained
fairly well the problem of pricing and the approach you're taking to
building out these APIs to help people work on their pricing and iterate on
pricing plans and make changes quickly.
how is Stig using Stig to to work on your own pricing and to, to tests
and evaluate what you're doing?
Anton: Yeah, so basically our, our own pricing is Bill using our own components,
our own widget, like our, if you go to a pricing page, you'll see those pricing
plans and it's there's a badge of power by stick that's basically one of our
widget that we that we are using our own.
And I think that like a stake the core concept of pricing
is basically the ability to.
. So we are modeling our own pricing using Stig, and we also
leveraging our capabilities of experimenting with this pricing.
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.
Mike Bifulco: Sure.
Yeah.
It's, it's surprising the amount of difference that can make for an early
stage business too, being able to hone in on exactly the right price
strategy and, and price levels that your customers are willing to pay for.
A lot of it can be based on feedback and things like that,
but experimentation helps too.
Anton: Yeah, I think experimentation will, will be like a, a core feature
in price and packaging solutions.
I think that experimentation allows you to make mistakes and mistake those
mistakes won't be as costly as, as a mistake that you can often undo.
Like every time, like even, you know
When we build software, there's like, usually there's bugs.
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
Mike Bifulco: Yeah, I can see that for sure.
Anton it's been really great chatting with you today.
One of the things I wanna make sure I ask is, where can people find you?
Where's the best place to chase you down if people have
thoughts or questions for you?
Anton: Yeah, sure.
So you can find me on LinkedIn.
I think like also pretty trying to be active on GI as well.
I'm not a big Twitter user unfortunately.
I know that's missing something, but I don't have an Instagram,
so yeah, I'm not a good
Mike Bifulco: Got it.
Anton: Another, a good example of being to into social platforms, but
I think that LinkedIn and GI are,
Mike Bifulco: Yeah, well,
Anton: the
Mike Bifulco: you're a focused man.
There's no, no need to apologize there.
That's
that's good stuff I've also Twitter recently, so you know,
people have heard me endlessly complaining about I dislike Twitter.
Yeah.
That's wonderful.
I'll, I'll make sure I link to your LinkedIn and, and GitHub
profiles in the show notes as well.
Yeah.
Thanks so much for joining today, Anton.
I really appreciated chatting with you.
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.
Anton: Yeah, me too.
Thanks for having me.
I had a good time.
Mike Bifulco: course.
Yeah, thanks.