Kevin is the VP of Engineering at Abnormal Security, overseeing all aspects of growth and execution. In this class, he walks through the steps required to create and support a SaaS product from an engineering perspective, with a particular focus on what aspects to prioritize in the early days of your product. Kevin spent time at eBay and Quantcast prior to becoming an early-stage engineer leader at TellApart, then a Director of Engineering at Twitter.
I think this is one that we've been, experiencing a lot [00:16:00] more as we start to think about, using, off the shelf or third-party vendors versus our in-house kind of built technology to normal.
Kevin W: I think there's a lot of different things I have go through. I think the first thing that's probably very critical for you to think about is, how core and proprietary or critical is this particular part of your tech stack to your core technology and obviously the more core and mission critical it is to your company.
Success. Probably the less likely that you'll want to outsource that in some way, either to off the shelf technology or to a third party. Cause that's one thing that's really critical that changes of course, company by company, by product. The second thing I've thought a lot about for this one is really makes a lot of sense to prioritize, switching costs.
And seeing if it really backing yourself into a corner where the vendor lock-in right. If you happen to be heavily reliant on that single feature that AWS is offering that no one else out there does, you basically have backed yourself in a corner where it's gonna be very difficult to change one of your infrastructure providers.
Kevin W: If you choose, [00:17:00] you need to, for whatever reason, right down the line. I've always tried to think through, and I've heard this from other leaders in the space as well, that you want to try to use solutions where you have at least two options off the shelf for, from third-party vendors as well, because that helps you with some of that switching costs, The longterm. And then I think the third thing that you know is usually one consideration here is cost, right? Both the monetary cost to use a third party solution, as well as the internal developer cost to maintain and scale out. And. Develop right. That actual solution. And of course, you're trying to reduce costs to build the most value for your customers over time.
And you have to evaluate, is it cheaper for me or is it better for me to redeploy the engineers? Who'd be working on that particular technology. Or an alternative. If I could get that off the shelf in an existing framework, I could redeploy them to mission critical business logic, Or the unique value I'm adding to my customer.
So as usually some of that calculus, I think those three kind of areas, how critical is this particular feature technology to my, company's core IP and core value prop. The [00:18:00] switching cost and optionality that I want to maintain. And then in my technical decisions, and then thirdly, the cost, Both financial, but human costs taken, based off of what, which decision you end up taking.
