Learnin' about webhooks, with Tom Haconen from Svix

[00:00:00] 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?

[00:00:45] tom: Yeah, I'm great. Thank you. How about yourself?

[00:00:47] 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 [00:01:00] 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.

[00:01:18] 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.

[00:01:42] 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?

[00:01:50] 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 [00:02:00] 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.

[00:02:16] 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?

[00:02:56] tom: Yeah. You know, so the people we interact with a lot are the people [00:03:00] 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 [00:04:00] 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.

[00:04:17] 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 [00:05:00] 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.

[00:05:45] 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 [00:06:00] 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.

[00:06:11] Track 1: Yeah, sure. Yeah. So how, how long ago did you start in on this journey? When did fix.

[00:06:16] 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,

[00:06:22] Track 1: Sure. And so I guess tell me about that. How did you identify the need for, for the, the service to exist?

[00:06:27] 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 [00:07:00] 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.

[00:07:40] 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 [00:08:00] 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?

[00:08:41] 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 [00:09:00] 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,

[00:09:48] 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 [00:10:00] 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?

[00:10:51] 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, [00:11:00] 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,

[00:11:22] Track 1: Yeah. Developers love a good scholarly debate. I don't doubt that

[00:11:25] tom: Yeah, exactly.

[00:11:27] 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?

[00:11:35] 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,

[00:11:54] Track 1: sure. Yeah. I guess I can see the need for both.

So,

tell me a little bit about, I guess then the [00:12:00] experience of someone who's trying to onboard, onboard to space. What's the I guess the developer story look like?

[00:12:05] tom: yeah. So like six customers.

[00:12:07] Track 1: Yes. Yeah.

[00:12:08] 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 [00:13:00] 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.

[00:13:16] 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.

[00:13:29] tom: Oh, you now I need to remember all of them. So

I

[00:13:31] Track 1: there's a lot.

[00:13:32] 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.

[00:13:51] 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 [00:14:00] libraries functioning and well cared for?

[00:14:01] 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.

[00:14:19] 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 [00:15:00] ecosphere. I think that's really good sign.

[00:15:01] tom: Yeah I

[00:15:02] 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?

[00:15:08] 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.

[00:15:42] Track 1: Sure.

[00:15:42] 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 [00:16:00] 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.

[00:16:07] Track 1: Oh, that's really interesting. Yeah. So where does that run?

[00:16:10] tom: On our, our environment. We use Dino for that.

Yeah. it's kind of isolated like it's, it is on mini microservice.

[00:16:17] 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?

[00:16:28] 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.

[00:16:50] 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 [00:17:00] 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?

[00:17:15] 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.

[00:17:41] 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,

[00:17:56] tom: Yeah. And, and you know, it's kinda like all of those things are like, it's, you know, silly, [00:18:00] 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.

[00:18:14] 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.

[00:18:58] tom: Yeah. I mean, I, I couldn't [00:19:00] 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.

[00:19:18] 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.

[00:19:33] 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 [00:20:00] 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.

[00:20:46] 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 [00:21:00] 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.

[00:21:35] 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.

[00:21:43] 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, [00:22:00] 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.

[00:22:25] 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

[00:22:45] Track 1: philosophical. I

[00:22:46] 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 [00:23:00] 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 [00:24:00] 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.

[00:24:18] 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?

[00:24:50] 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 [00:25:00] 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,

[00:25:59] Track 1: Sure, yeah. [00:26:00] 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.

[00:26:17] 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.

[00:26:45] 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?

[00:26:53] tom: So we are five at the moment, like five engineers.

Yeah. .

[00:26:58] Track 1: Yeah, that's that's a, a [00:27:00] 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

[00:27:12] 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

[00:27:27] 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

[00:27:34] 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.

[00:27:42] 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.

[00:27:57] tom: Yeah, I mean, you can email me [00:28:00] directly@tomatvx.com or just we have a community slack at vx.com/slack. So just jump in, have a chat. Happy to

[00:28:06] 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

[00:28:12] tom: Yeah. Already

filled. Don't worry, .Yeah.

[00:28:16] 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

[00:28:43] tom: Yeah. Thank you. It was great. Great being here.

[00:28:45] Track 1: Likewise. Take care,

[00:28:46] tom: You too.