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.
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.