Stigg: https://www.stigg.io/ - API-first pricing and packaging
Stigg is Hiring: https://jobs.lever.co/stigg
—
Creators & Guests
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.