mike: Hello and welcome
to APIs you won't hate.
My name is Mike Fulco, your
host . I'm here today chatting
with a new friend of mine.
And we're gonna dive into something
that I think is an interesting topic
for lots of devs of various flavors.
And it's something that comes up
for me I think fairly often when I'm
talking to developers who are sort
of like thrust out into the wild for
the first time and have gone past.
I don't know the 100 or 200 level
tutorial experience of building things.
It's a topic that it comes in handy if
you're building anything that uses dynamic
information that I'm sure you'll run into
from time to time, especially if you're
building APIs with information that has
any sort of real time component to it.
And of course that means the elephant
in the room today is webhooks.
And so we're here to chat about webhooks.
I'm talking today to
Tom McConn from S spx.
Tom, how are you doing today?
tom: Yeah, I'm great.
Thank you.
How about yourself?
Track 1: I am doing really well.
Thanks.
Yeah.
Thanks for taking the time to talk to me.
I am gosh, I would say I'm, I'm the
dangerous kind of web hook user in
that I've consumed them many, many,
many times with reckless disregard
for my own health and wellbeing.
And I have lots and lots of
feelings on using web hooks.
But to be honest with
you, I've never built the.
Event side of web hooks, the
side that emits web hooks.
So I've got lots of questions for you
there, but maybe let's take a step
back first, and let's start with this.
Can you tell me what Web hooks are?
Give me like the, the 100 level
description of what a web hook is and
why someone might be interested in them.
tom: Yeah.
You know, th this is a question I'm
always iterating on, so if someone
from the audience has a better
description, I'm willing to listen.
I, the way I describe it is
kinda like a reverse api.
So if an API is you making a request to
a server, you know this a web hook is
the server making a notification to you.
So kinda like a server to server po push
notification or like any event emitting.
Yeah, I give you few versions.
I hope choose the best one.
Track 1: Yeah, sure.
I think, I think that's fair.
So what are some examples, maybe
common examples where people might
have run into web hooks or use them
whether they realized it or not?
tom: Oh, so literally everywhere.
You know, so like if you've ever used a
product that uses Stripe you've used web
hooks without realizing it, because that's
usually how Stripe notifies people that
someone has paid or like an or someone
is delinquent or anything like that.
You know, when you receive an email
on Gmail, it submits a web hook to
your c r m or anything like that
to let it know that someone's pay.
So that sorry that an email was received.
I mean, literally
everything I can give you
every interaction that you,
that happens in synchronously.
Track 1: Yeah, it's true.
They are all over the place.
And I, I think Tom, actually, you just set
a new record for how early in the show.
I need to give my disclaimer
that I used to work for Stripe
and I no longer work for Stripe.
So we're, we're not
associated with Stripe.
Although obviously no
negative feelings there.
I just feel like it's one of those
good transparency things that
us people in the world of Derell
need to do a little more often.
But yeah, certainly in, in my role working
at Stripe and as an end user of Stripe,
I've, I've used their WebBook stuff quite
a bit, so, From my perspective and sort of
from my observations of the way devs learn
and the way devs get things done, it seems
like webhooks may be a topic that's kind
of intimidating for a lot of developers.
Can you talk a little bit about why
using webhooks maybe feels hard,
or is hard, or is challenging?
tom: Yeah.
You know, so the people we interact
with a lot are the people sending,
but let's start with actually
from the people consuming, which I
think is where you're going with.
So I think the first thing is,
You know, it's kinda like it's
something that's incoming, right?
And that means you need to use a tool
like En Grok or we have a tool as well,
like six play in order to kinda like
punch through the firewall and actually
get it to your local development server.
It's not, it's not one of those things
that you can just make a call from your
computer and everything just works.
It kind of requires this initial setup.
The second thing is, you know, we
spend, you know, all of us are like
day in, day out building like HDP
services that kind of like follow
this pattern of like getting a.
doing some magic.
making a response.
And that is like a, you know, a
paradigm that we're really used to.
But like, kinda like with webhooks,
we don't even know, like, when are
they coming, why are they coming?
You know, like we, we have this
kinda like lack of visibility of
like the trigger that makes it start.
And then the last thing, which I think is
the most, the most this is another one as
well, you know, like when you, you need
to validate the signature of web hooks.
And a lot of frameworks
actually go in the way of that.
They kinda like pause and re serialize.
The, the payload, which can, you know,
for, for encryption or for like anything
with cryptography can mean havoc.
And then the last part is kinda
like event-driven architectures
which are just more difficult.
It's super hard to reason about you know,
knowing when an event actually triggers.
I mean, I think they're probably
more, but I thought, I think
those are the main ones.
Track 1: Yeah, that covers it fairly
well to revisit some of those.
I think the validating web hook is an
interesting problem and one of those
things that like, certainly the first few
times I was an end user of web hooks was
something that I hadn't even considered.
But from the developer's perspective, the
way you receive an end hook is you open
up an http endpoint, so some URL that
some service can send a call to, and you.
Accepting information
through that endpoint.
So they send, you know, to
the specific URL that you set
up a packet of information.
And if you just trust that blindly,
what you're not doing is making
sure that the right person is
sending you that information.
So again, it's a public url.
Anyone can hit it.
Anyone can send any information there.
And by coming up with some way
to use encryption to validate who
is sending you that information.
You can reject WebBook calls that are
coming from bad actors or crawlers
or, you know, people who've just
stumbled upon your API endpoint.
The event-driven architecture one is
really interesting I think as well,
because especially in a world where
people are Expecting their applications
to feel a lot more real time and have
this like native mobile app experience
as the, the default expectation
for just about anything on the web.
We're very different from, you know, 10
years ago when you were expected to go
back and refresh a page to see changes.
That's just not the world
we operate in anymore.
And driving your UIs updates
through events that come in from
webhooks on whatever level, however
often that may be, can create that
dynamic effect quite a bit more.
So with all that being said, I think
that's some really good background on
web hooks, and I think that sets the
stage pretty well for, for you, Tom,
and sort of for where you are right now.
So tell me about fix and tell
me about what you're working on.
tom: Yeah.
So we do web hook sending as a service.
So essentially we help
companies send webhooks.
You know, they're kinda like a lot
of, you know, we talked about the
challenges of receiving webhooks.
But there are a lot of
challenges with sending them.
And even in a way, this challenge of
receiving them are also part of the
challenges of sending them because
you need to understand them well.
You need to sign correctly.
And all of those things that
we just covered, you need to do
it on the sender side as well.
So we really just turn all of
that into a simple API call.
Yeah, I think that's that.
Track 1: Yeah, sure.
Yeah.
So how, how long ago did you
start in on this journey?
When did fix.
tom: Wow.
Actually more than two years.
I was gonna say almost two years, but
more than two years at this point.
Yeah.
So a while back,
Track 1: Sure.
And so I guess tell me about that.
How did you identify the need for,
for the, the service to exist?
tom: yeah, so I had a different you know,
project side, project company, whatever
you wanna call it at that point that
I actually still running on the side.
You know, people who kept on asking
us for web hooks, like all the time.
And we know that A, we don't have the
upfront, like all the upfront costs,
like all the effort to build it,
we're like, we didn't wanna spend it.
And then like, the ongoing
effort of like maintaining it,
that sounded like hell as well.
So we kinda like skipped that.
A and then kind of like the last part
of it, which is, you know, we built this
like beautiful, beautiful p i and we spent
so much time on it, we're not gonna have
a terrible web hook experience, right?
So kinda like multiply the first
two estimates by like 3 0 5.
And kinda like all of that
just meant, meant that we.
actually built web hooks.
And I wish I could say at this point,
like, you know, I was smart enough to
realize that this is a problem that n
needs to be addressed, but I wasn't.
It took a few months later when
someone asked a silly question about
web hooks in a slack I'm a member of.
And I kind of like, well,
this person is smart.
That doesn't make sense.
I kind like dug deeper and I realized
she actually didn't wanna understand
anything, anything of what I was saying.
All she wanted was to send WebBook
and not have to think about it.
And I'm kinda like,
huh.
If I build it for you, will you pay me?
She's just like, yeah, and
then someone else chimed in.
I'm like, huh, maybe there is something.
I remember I had a problem as
well, so like decided to give
it a go and everything kind
of like went on from there.
Track 1: Sure.
Yeah.
I mean, maybe that's, that conversation
is exactly the reason that I
started this podcast by saying I've
never bothered to create WebBook.
I've only ever consumed them.
The, the thought of having to do that
honestly is, is a fairly intimidating
thing because of all the architectural,
this and that, that goes into it.
One of the things that happens, I think
with the event driven architecture that
is really tricky is like these web hooks
are asynchronous communications that you.
The emitter send out
when something happens.
But as the consumer, you need to think
about, well, what happens if I miss that?
You know, if someone sends a web hook
and my service is down or off, or
glitches out, or whatever the case may
be, has that thing gone into the ether?
Like that's, that's a very intimidating.
Perspective to have, you know,
something like that going wrong,
especially when you're dealing with
like finances FinTech, things like that
missing a deposit or a withdrawal can
like fully wrangle the books
incorrectly if you want.
So there's a lot to think about there.
So your first customers then were,
were developers, were looking to
send out an emit, emit webhooks.
What does that look like
from their perspective?
Are they sending you something
like an open API definition?
Are they calling a service?
Are they.
Self-hosting something
that's fixed stands up.
What, what is the infrastructure?
tom: Yeah, so it's kind
of like all of the above.
We really believe in meeting like
customers where they want to be.
You know, we have very strong
opinions on how things should be
done, but that doesn't mean, you
know, we know we are not always right.
So it's better to kind
of like help people.
So I mean, like what the, the main
gateway to our service though is
either R SDKs or H T HTTP requests.
And people, you know, like
every six integration is kind
of like two and a half steps.
So the first
one is creating a destin.
So kind of like, you know, whenever a
user signs up to your service, you create
what we call a consumer application,
and then you send web hooks to that
location, and then the second API
call is just to send that, you know,
that web hook to that location kind of
saying like, Hey, an invoice was paid.
The, these are the details,
just go and send it on.
As you may have noticed, we actually
didn't, I didn't talk about adding
the actual HTP endpoint yet.
For that step, we offer two things.
Either they use the API to do
it and they can do it, you know,
like from the front end, from the
backend, whatever they wanna do.
Or we have like an eye frame that they
can embed in our ui, in their ui, sorry
in order to let their customers kind,
like, control all of that to kind of
have like a very, a turnkey solution.
Two and a half.
Two and a half.
API calls,
Track 1: Yeah.
Okay.
It sounds like it.
I think I've actually used that
iframe service through a clerk I've
been using clerk for authentication
for, for my new company.
And it's really interesting
to consume that, right?
Like I get as a user of clerk.
There's an embedded
interface from fix there.
And I think this may be how I
first came across Fix in the Wild.
but essentially it's an interface that
allows me to define URL endpoints that
web hooks end up at whether that's
sort of my local host environment
or you know, pipe two and actual
say production or staging U r L.
And having worked formally
in the past, For Stripe.
I think it, it does a pretty good job
of mocking some of the best parts of
that too, where Stripe has all this
tooling available via CLI, via ID
integrations and their dashboard and
all these other places where you can
tell Stripe where you want them to
pipe information to when events happen.
And I think SPH does that really
well in a way that I hadn't really
considered as something that a
product developer might want to use.
So I guess this brings me back to
then What's it like to plan for those?
Like do you find yourself having
to educate your customers?
What they, what the ideal sort of user
experience looks like for their consumers?
tom: Oh, a hundred percent all the time.
But I think the nice thing is that
they come to us already as experts
and they realize that we've seen.
a ton of integrations, both
ones that follow our best practices, ones
that existed before us, and then they
migrated to VX and just, you know, like
market research that we do all the time.
So education is, is less painful than
it has to be because they really are
coming, like willing and like, you know,
willing to learn and willing to listen.
But we do get every now and then we
good get into like let's say healthy
arguments about the right thing to do it.
Yeah,
every now and then,
Track 1: Yeah.
Developers love a good scholarly debate.
I don't doubt that
tom: Yeah, exactly.
Track 1: that most of your customers
tend to have already had web hooks and
they're looking to move to a less painful
implementation, or they're creating a
web hook experience for the first time?
tom: You know how to say, we see
the whole gradient, so we see both.
They had a mature implementation
for a few years now, and they're
like, they've had enough maintaining
it and they wanna switch.
They've had a terrible implementation
that they kind of hacked together,
cobbled together for like a few months
and now they're looking to switch.
And also they just wanna.
With something.
So really we see the whole
gradient, hard to say,
which is Yeah,
Track 1: sure.
Yeah.
I guess I can see the need for both.
So,
tell me a little bit about, I guess
then the experience of someone who's
trying to onboard, onboard to space.
What's the I guess the
developer story look like?
tom: yeah.
So like six customers.
Track 1: Yes.
Yeah.
tom: You know, so, the way I look at
APIs or like in products in general,
you know, like think I'm not an apple
fanboy by any means, but like think
of like when you buy a new Apple
device, like a new iPhone, for example.
You get a box, you open it and you get
a phone, and then you pick it up, you
turn it on, you start using it, right?
That is kind of like,
that is the experience.
You don't read a book before.
You don't need any of those kind of
things, and we really try to mimic that as
much as we can in order to make sure that.
You know, our customers
don't get frustrated before
they need to understand it.
And, you know, they can
read the docs afterwards.
So the first thing when you sign
up, you kind of see essentially like
a one paragraph that explains what
consumer application are, which I
explained a moment ago actually.
I mean, we, I think we went through
the onboarding mentally a moment ago.
So like the, you know, Yeah, they, we
explained what consumer applications
are and then we have a Kell command
that they can just copy paste to the.
And that's their first API call.
It actually works.
And then they pro automatically
progress to the second page where
again, we explain what messages are.
They copy paste that telco
command and there you go.
They send the first message and then kind
of like we, we let give them a button to
move to that embedded ui, or we have a
button to move to the docs and kind of
like read more about how to create that.
Track 1: Sure.
And then they can grow from there.
And so is your functionality
through six, it's not just done via,
via like plain CTP calls, right?
I think you have quite
a few client libraries.
Can you talk a little bit
about the languages that you.
tom: Oh, you now I need
to remember all of them.
So
I
Track 1: there's a lot.
tom: Yeah.
there's a lot.
So like Python, we have a version
for both Async Python and Sync,
Python, JavaScript type script.
We have one in Java, one for Colin.
That is actually different because it
uses like you know, async Colin rust.
I think I mentioned that.
C.
I think that's it.
Oh, Ruby.
Yeah.
a few of them.
Yeah.
Track 1: There's a lot which to me to, to
my ear, that sounds like it must be quite
a bit of maintenance challenge as well.
Right.
Do you have a pretty large engineering
team working on keeping these libraries
functioning and well cared for?
tom: Yes and no.
So no mostly, no.
We had like one, two, I think two
of the libraries were contributed
by the community and we employ a lot
of tricks in order to like auto generate.
A big chunk of them.
But it's still a pain.
It's still definitely a pain
to like update things, even
though a lot of it is altered.
Yeah.
Track 1: Yeah.
Yeah.
I think this is something that API
providers are thinking about more
and more is you have quite a few, you
know, flavors of consumer these days.
And especially like, I'm the first
to tell you I'm not a Python expert.
I can look at some Python
code and, and wrestle my mind
through what's going on there.
But it was only fairly recently that
I, I came to understand that like
Async Python was a challenge and was
something that was sort of a different,
you know, developer experience.
So I, I think.
, having devs on staff write engineers
who, who work for you with you,
who are able to produce libraries
and all these different flavors is,
is going to be an important thing.
And definitely like having community
support is always a good sign too
when you're getting open source
contributions because people want to
be able to embed themselves in your,
your product and your ecosphere.
I think that's really good sign.
tom: Yeah I
Track 1: yeah.
Yeah.
That's, that's really interesting.
Are there, so what's the world
look like for fix right now?
Like what, what's the breadth
of products that you offer?
tom: You know, so as I said,
it's kind of like an onion.
So the first thing that we do, we
kinda like, we just make it possible
or make it easy to send web hooks.
And then we also have a tool that's
called Slicks play which is both
like a c l I, kind of like enro,
like, but just very specific.
I mean, if you want anything
more robust, use Enro.
But for, it's kind of like
agro, but you know, like a
quick testing thing with a ui.
In order to make it
easier for consumers, we.
A wide range of open source
libraries for verifying web hooks.
So our customers, and by the way, not
our customers as well, like anyone
can just use them to sign and verify.
And it's kinda like just much better than
like trying to reinvent the wheel there.
Track 1: Sure.
tom: And then kinda like the
Fixx product, you know, does like
everything you would want and more.
It's kinda like all the reach
wise and like manual and
automatic and like observability.
And we, we also have something
really cool that we call like
a payload transformation.
So we realize like a lot of our
customers, what they do, they receive
a WebBook, they do something to it,
and then they send it somewhere else.
And we realize we might as well
let them embed a bit of JavaScript,
kinda like run it there and,
and, you know, move it forward.
Track 1: Oh, that's really interesting.
Yeah.
So where does that run?
tom: On our, our environment.
We use Dino for that.
Yeah.
it's kind of isolated like it's,
it is on mini microservice.
Track 1: Sure.
That's a really interesting idea.
Then, then you get a little bit of that
transformation that's sort of offloaded.
Ha.
Are you finding yourself wrestling with
implementation of Edge services at all?
Is that something that you need
to think about as a, a provider?
tom: Not for us but a lot of customers,
you know, and, and this is kinda like
adjacent to what you asked, but like a lot
of our customers use those services, which
again, like going back to what we talked
about with the transforming the payload
and making it very e hard to verify.
So we do actually end up, you know,
we have actually, I mean we have
integrations with Netlify and we're a
cell, but we also have like tutorials
on how to use how to verify WebBook
for all of these environments.
Track 1: Right.
Yeah, actually I saw that.
I meant to ask.
So I'm, I'm both a Netlify and Versace
user for, for various purposes and
various little projects I have.
I know that they both provide,
I forget the language.
They use add-ons or
plug-ins or extensions,
whatever their terminology is.
But they, they make it pretty easy to add.
Auxiliary services, right?
Things that are sort of feature
add-ons for your application.
And I saw this fix comes
up in both cases there.
What does that do when, when
I click the ads fix to net?
tom: Yeah.
So Netlify is actually not as mature
as our reell integration is fairly new.
But Inify, it just helps you.
I think, actually, you know what?
I don't remember.
I think it just, at this moment, it just
like helps you with like the verification.
I
don't remember what is the extent
is there, but with versa, it also
creates an environment, fetches and
authentication token puts it in the, you
know, in the secrets and all of that.
But just
Netlify don't, don't have all
of that, all of those APIs yet.
So we haven't built it fully.
Track 1: Yeah.
There's a surprising amount of
manual steps to adding a new
provider to, to your application.
And usually the one that catches me
on my first deploy of anything is
I forget the environment variable
that needs to go somewhere, whether
it's to my hosting provider or to
CI or, you know, GitHub actions,
tom: Yeah.
And, and you know, it's kinda like all
of those things are like, it's, you
know, silly, what I just described is
like a very simple integration, right.
But it's kinda like, well if you, you
save people like a few annoying manual
steps that are gonna like, bite them in
the ass, like you said that is like a,
you know, a total win for society, A total
win for the development society, at least.
Track 1: Yeah, absolutely.
I don't, I don't really have a phrase for
this yet, and I wonder if it's something
you've thought about, but I feel like
day-to-day in the life of, of someone
building anything, any engineer at any
company, I feel like there's a moment
where you reach, like your level of, oh
man, this is one step too far for me.
Like the mental tax I've
paid to get there is too far.
Going to take me another day to
get this done, or I need to step
away from this at some point.
That, that's something that I've
experienced certainly in, you know,
like so right now I'm building a company
and, and every day is learning something
new and applying some sort of new, you
know, integration of things together.
But I see in a lot of the folks that
I work with as sort of mentors and
friends who work in the industry as well.
And I don't hear developer experience
companies talking about a lot, but I think
that's the ultimate like problem to solve
is if you're able to get rid of those
little bits of friction from developers
experiences, they sort of love your thing
more for being easier and easier to use.
tom: Yeah.
I mean, I, I couldn't agree more.
That's, that's why, you know, we don't.
that that's why like this, the, the curl
command that you copy already has an OR
token that's temporary for the onboarding,
already has all of those things.
Because even just telling people, Hey,
replace the OR token here kind of thing.
It's like already way too much for someone
that doesn't care about your product yet.
Yeah.
Track 1: Yeah.
If, if you really break it down,
there can be quite a few steps to
getting any of these things done.
And you know, the ability to compound a
couple of steps behind the button that
says install on, you know, X provider
is a really nice thing to be able to do.
So we talked a little bit
about what Fixx does currently.
What are the things you're
thinking about for the.
tom: Ooh.
You know, so like one, one thing that we
are very excited about, and this is, it's
just like web hooks in general, right?
I mean, it's not even just web hooks,
you know, like the way, when you think
about how, you know, like, kind of
like the Unix philosophy of kinda like
one thing, one tool that does it well.
and kinda like all the tools
are separated, you kinda like
concatenate them together.
I think we reached a point where the
internet is almost kind of like the
database is the wires kind of thing.
And we make an action and like we
don't need to persist anything.
Like a message is being sent there
and they do something and a message
is sent there and they do something.
And kind of like all of this, like
workflows and you know, like even see
it when our product, we use off zero
for authentication, strive for payment
mail, gun for emails and people use us.
God ask for web hooks and, you know, clerk
for authentication again and max for video
and kinda like you have all of those.
Interactions and what we just wanna
do is we wanna make those reliable,
more widespread and exactly what
you were referring to earlier.
Kinda like removing, even like
when the beginning of this chat,
like removing those like annoying
extra steps that people need to do
in order to ingest those events, I
think like gonna be a massive win.
And we kinda like we all just
marching in those directions, making
it easier to send, more useful to
receive, and easier to receive.
Track 1: Yeah, sure.
I think as people who are on, on
teams that build things, I think we
all benefit from that too, right?
Like it's, it's always nice to see when
a company's goals align with the better
need of the, the developer community too.
You know, you're not putting artificial
tiers in place to, to make more money.
You are literally making
the process of making these
implementations better for people.
And I really like the idea of also
releasing, you know, open source
tools to help people do it, whether
or not they're embedded in your, your.
Stack.
I think that's really one of the things
that I like, especially about the,
the world of sort of API developer
community stuff too, is like a lot of
the tooling we work on and a lot of
the people we work with are all working
with each other and sort of allied
together to, to make our lives easier.
Cuz ultimately, like we are all successful
when our end users are successful, we're
not successful because we've, you know,
stomped on the competition necessarily.
I think that's really one of the
things I like about the world
we get to live in, I suppose.
tom: Yeah.
I mean like the developer.
It's also like the open source mentality.
Which is kind of
like, Yeah.
it's great.
I agree.
Track 1: Yeah, yeah, definitely.
For sure.
So I'm, I'm a couple more questions,
I guess, about fix, and I, I want
to talk a little bit about sort of
your perspective on leading a company
as well, and especially in, in this
sort of changing atmosphere we've got
with economic changes and whatnot.
but I, I, before we get
there, let's, let's do this.
So I'm really interested in
I guess who, who you think.
Lemme take a step back.
Our audience for APIs you won't hate
are all API developers of some flavor.
Probably they're all API consumers
on some level, and many of them are
probably writing APIs that require
web hooks to be emitted at some point.
What do you think is the point where
someone needs to realize that, Hey,
maybe I should be considering taking
advantage of a service like this.
Like, how does someone identify,
oh, I should be looking at fix,
I should be looking at, you know,
whatever's out there in the.
tom: Yeah.
So.
You know this, it's like the eternal
question of like build versus buy.
And when I say
buy, I don't even mean like pay money.
I mean like using an existing product.
Could be open source, could
be free, you know, develop.
There's just like so many.
We don't have that much time on
Earth in general as individuals.
I know this became a
bit morbid, sorry, but
Track 1: philosophical.
I
tom: Yeah.
But we, we don't have
a lot of time on earth.
We don't have a lot of time to
finish those goals that we want.
And, you know, especially like
early stage startups, all we want
is to make our customers happy.
So when it came like.
you know, the point for us, like,
do we build X or do we use off zero?
We chose off zero, right?
Because we, we don't care about those.
We wanna just give our
customers what they want.
So I think like, if you are resource
constrained, definitely like you
need to look at a third party.
And, you know, you know, you can
always, like, as I said, like
our libraries are open source.
You can always switch us out.
If we don't make you happy, it's our
job to kind of like make sure that
we keep constantly, make you happy.
So I, I think the second part is, it's
kind of like when you reach a certain.
Scale where actually the
maintenance is becoming annoying.
Like if you look at some of our use
case, like case studies on the website
you see that, you know, like just
bringing back, you know, you kinda
like, you've spent all of this kind
of time convincing these amazing
employee, you know, like team members
to join the company and work on.
you know, payments or work on whatever it
is that you're building, and then all of a
sudden you are sending them off to like a
small team that does infrastructure work.
They're not gonna be happy about that.
And they're gonna be, you
know, you're gonna be like a
lot of like movement there.
Either they're gonna like leave
the team or join a different team.
So it's kinda like it becomes this
like core infrastructure that no one
knows very well and no one cares about.
So I think the moment you start
realizing it is something you care.
That's the time to professionalize it.
Professionalizing it
either means a dedicated, strong team that
has buy-in to this or outsourcing it, that
that's the way I look at those things.
Track 1: Sure.
I appreciate that quite a bit.
I both didn't expect this answer to be
quite so philosophical, but also really
appreciate your ability to, to turn
that into a framework for recognizing
you know, what the opportunity looks
like and when to, to jump on top of it.
I think that's actually
pretty sagelike advice there.
Yeah, Tom, I think that's really great.
All right, so let's pivot a little bit.
I'm interested in hearing what your
what the process is, or, sorry,
not the process, but what it's
like leading in your, your company.
Like what are you finding are the
challenges of, of growing, of building?
What are the things that, that
keep you excited about working
on a, a product like this?
tom: Yeah.
Wow.
That's a big question.
I really.
I enjoy almost everything.
You know, if you look at our
slack, I do a lot of support.
I enjoy talking to our customers,
and I kind of like seeing what
they want and what they're asking.
I enjoy jumping on calls and helping
customers like find out the, the best
solution for them and what they need.
Engineering, you know, I've
been coding since I was nine.
It's still like a soft place in my heart.
Really just everything.
What keeps me up at night.
Is making sure that we build the
right thing for our customers
which is not very obvious, right?
I mean, like, there's like one end
of the spectrum, which is like just
saying yes to whatever they ask for.
And this, this is a terrible.
Terrible way of building a product.
But the other end, which is
like say no all the time, also
comes with its challenges.
And it's kinda like you need
to balance both of these.
Kinda like knowing when to say yes,
when to say no, and while keeping your
customers happy, because you know, at the
end of the day they're outsourcing this
huge chunk of the infrastructure to us.
So like how can we make sure that we're.
Trusted partner and not this annoying, you
know, brat that always says no, whatever.
So it's kinda like, it's really
like a tough balance to to keep,
Track 1: Sure, yeah.
That's the eternal struggle balancing
needs and, and desires and especially
demands with like the moment you've
started serving customers, you can
find out who your louder customers
are and the ones with stronger
opinions, and that's not always
best for them or for the business.
But you need to kind of distill that
information into good decisions, you
know, both for your business and theirs.
It's a tricky thing.
tom: Yeah.
I guess another part as well is kind
of like going back and fixing things.
So kinda like technical
debt versus marching on,
Which is especially relevant
for company like hours because
you know, the moment we.
Onboard a customer.
Like, I mean, Microsoft is not a customer,
but when the moment we onboard Microsoft
as a customer, we're Microsoft Scale.
And then Amazon is a customer
with Microsoft and Amazon Scale.
So it's kinda
like he keeps on like you know, it
keeps on like jumping as like a,
a, a menacing step function that
we have to always be aware of.
Track 1: You make it
sound like a horror movie.
Yeah.
. Without a doubt.
So I, I wanna talk about, about
your company's growth then too.
Are you how big is your
engineering team right now?
tom: So we are five at the
moment, like five engineers.
Yeah.
.
Track 1: Yeah, that's that's
a, a solidly small team for the
amount of output you've had.
Especially like looking at this list
of climate client libraries that you
rattled off before, you know, to 10 or
15 different flavors of, of spic exist.
That's really cool.
Are you expanding, are you hiring for any
tom: Yeah, we are hiring.
We, so we just recently raised
around with Andre Howorth and we
have like, you know, a, a big chunk
of it is like hiring more engineers.
You know, we we're lucky to have,
you know, like a high output team.
But I think we can even do even more.
We just like more people helping out.
Yeah, very excited about
Track 1: Yeah, sure.
And if folks listening to the show
are looking for a job, where's
the place to go to see your
tom: Yeah.
Vx.com/careers.
But also if you think we should be hiring
you and we don't have an opening email us.
Anyway happy to chat.
Track 1: I like that.
That's solid perspective.
I will obviously make sure that
there's a link in the show notes too
to your careers page and, and just,
you know, speak and some of the other
things we've chatted about here.
What's the best place to find you, Tom?
If some of our, our listeners want
to shout at you about web hooks or,
you know, their thoughts on open
source or whatever the case may be.
tom: Yeah, I mean, you can email me
directly@tomatvx.com or just we have
a community slack at vx.com/slack.
So just jump in, have a chat.
Happy to
Track 1: Perfect.
Yeah, will do.
I'll, I'll include links to those as well.
Hopefully we don't fill
your spam coffers too
tom: Yeah.
Already
filled.
Don't worry, .Yeah.
Track 1: Yeah, me too.
I, I can definitely relate to that.
Something about having an easy name
and then@yourcompanyname.com makes
it real easy for people to find you.
I think.
Yeah.
Now that I've said that, I'm sure
I made it worse for both of us.
Tom, thanks so much for coming
to hang out with me today.
It's been really
interesting talking to you.
I am looking forward to you obviously
getting the use fix more in the future,
and I, I will likely end up be being in
your inbox one way or the other, asking
questions about web fix as things go on.
We'd love to have you come back
anytime if you're interested
in talking a little bit more.
But thanks for joining today.
I really
tom: Yeah.
Thank you.
It was great.
Great being here.
Track 1: Likewise.
Take care,
tom: You too.