APIs You Won't Hate


Stigg: https://www.stigg.io/ - API-first pricing and packaging

Stigg is Hiring: https://jobs.lever.co/stigg

Find Anton Zagrebelny onlin:  Linkedin - GitHub


Thanks for listening to APIs You Won't Hate

Creators & Guests

Host
Mike Bifulco
Cofounder and host of APIs You Won't Hate. Blogs at https://mikebifulco.com Into 🚴‍♀️, espresso ☕, looking after 🌍. ex @Stripe @Google @Microsoft
Guest
Anzon Zagrebelny
Co-founder and CTO at Stigg.io

What is APIs You Won't Hate?

A no-nonsense (well, some-nonsense) podcast about API design & development, new features in the world of HTTP, service-orientated architecture, microservices, and probably bikes.

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.

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.