The End of Manual Debugging

[music] I am excited to welcome Sherwood from Sasabi who has exited his first YC company and is coming back through the YC batch again for a second time.

Sherwood, thanks so much for joining.

>> Yeah, really excited to participate in the upcoming YC batch. Uh be back here for a second time. I think it's going to be a really different experience and to uh introduce Sabi to to the batch and to into the world. So

>> yeah, amazing. So maybe to start off um tell us a little about what Sasabi does.

>> Sazabi is an AI native observability platform. It's specifically designed for

platform. It's specifically designed for fastmoving engineering teams. Um and one way to think about it is like it's like a data dog or a century but instead of being built in 2010 or 2012, it's built

in 2026. And it's aggressively AI native

in 2026. And it's aggressively AI native or uses a lot of AI agents. Um, and the idea basically came from this uh experience I've had uh over the course of my engineering career where every

time there's an outage in production, every time there's a bug, I would spend hours digging through dashboards and log searches and looking at flame graphs and kind of not really knowing what's going on. And eventually I might get to the

on. And eventually I might get to the root cause, maybe not. Uh, I felt like AI coding tools had gotten very powerful and the the part of my job that involved creating new software was was really

changing. But the part of my job that

changing. But the part of my job that involved maintaining existing software wasn't really changing. With Suzabi,

customers can basically ask questions about how their production system is doing. Uh they can ask things like uh

doing. Uh they can ask things like uh why is production down or what does this error mean or which customers are affected or which commit is responsible?

Uh and it makes it very easy to to find and fix production issues.

>> Amazing. And you you kind of have a controversial take on this and how you're building it that it's just built off of the log files, right? Tell us a little bit more about that.

>> Yes. So, one of the things that we say at Sabi is logs are all you need. And

it's actually one of three different uh sort of hot takes that we have. We call

them our core principles. They're part

of our manifesto which we we published.

Logs are all you need specifically refers to this idea that we think you only need logs like only need this specific type of telemetry uh to do observability.

Um and that's controversial because in the past for a long time uh people would say that you need something called the three pillars of observability. You need

logs, metrics and traces. And uh that's because like these different data types serve different types of queries. And

then some data types are are large and some some data types are small. And so

for different types of things you you you end up using these different kinds of data. But the result is that you have

of data. But the result is that you have three different things that you need to instrument. So for every engineering

instrument. So for every engineering team out there, they need to implement uh logs, metrics, and traces for all of their services. That's a huge pain in

their services. That's a huge pain in the butt. Uh logs relative to metrics

the butt. Uh logs relative to metrics and traces are so much easier to use.

Like every developer knows how to do a print statement, and every developer knows how to read a a log stream. And so

we think that logs kind of represent the AAMS razor of observability. Like it's

anyone can do it. like it's the simplest possible way of of doing it. Um then

there's another thing which makes this true uh which is this AI paradigm shift.

So in the past logs were kind of the least valuable type of telemetry because they're mostly unstructur unstructured.

Um that's that refers to the fact that like the log line contains like natural language in it and you can't like have a machine read over it and derive a lot of insight. Well, obviously AI changes

insight. Well, obviously AI changes what's possible there and uh you can now have AI agents read all of your log lines and tell you what's going on. So

that's the idea behind logs are all you need.

>> Very cool. And obviously observability is changing a lot over the last couple decades. But um talk about how you got

decades. But um talk about how you got your start early on uh setting up observability at BS.

>> Yeah. So I started my career as a front-end engineer, but I was like the junior most front-end engineer at Crunchbase originally. And um because

Crunchbase originally. And um because you're junior like you don't get to work on any of the important stuff. So my

team was complaining about CI/CD and about how long their builds and deploys would take. So I went down this rabbit

would take. So I went down this rabbit hole which is CI/CD and figured out how to make our deploys faster. Uh and that led me to infrastructure and DevOps and which turned out to be something that

was uh really fascinating for me. I got

basically obsessed with this problem of like how do we make production reliable and how do we make developers more productive and allow them to to to ship faster and to ship higher quality code.

So I was already kind of primed and interested in that space and then I went to join BS where I was lucky to be um basically the third infrastructure engineer at Brex. Um I think it was

roughly employee 70 and they had just stood up what what they call their foundation team. My the second

foundation team. My the second infrastructure engineer I think had joined the same week. So I can't quite call myself the second but like really close. Uh and actually he works at Suzi

close. Uh and actually he works at Suzi today which is great.

>> Very cool. While I was at Brex first, we built out uh all of Brex's infrastructure that supported the company through hyperrowth. So all of our staging and and production environments, the microser framework, CSCD system. Eventually when we had

CSCD system. Eventually when we had rolled out like a lot of this basic infrastructure and the foundation team had grown a lot, we were in this position where we were starting to splinter the foundation team into different sub teams and focus on

different specializations.

And we had found ourselves in a position where we had like 50 different microservices running in Kubernetes as a part of our production cluster and they were all owned by different teams and some teams would own multiple

microservices and it was getting hard to kind of know what was going on in production. And so the answer I didn't

production. And so the answer I didn't know at the time because I was too junior but the answer is observability.

like this is the reason that observability exists is to help uh developers or engineering teams ask questions about their production systems. And so I was fortunate to be

one of the team members that helped start the observability team at BS. Uh

and then while working on on observability at Rex I became very observability pilt.

Basically like the observability philosophy is that you can you can have integration tests, you can have unit tests, you can have QA processes, you can have like release processes, you can do everything you want like static

analysis before the code goes to production to try to make sure that it's right and that it's going to uh behave well. But like nothing really prepares

well. But like nothing really prepares you for production. It sort of reminds me of that um that Mike Tyson quote where he's like, you know, everyone's got to plan until they get punched in the face, >> right?

>> That's so true of of shipping software.

Uh so once you're in a production, you just can't predict what's going to happen. You can only prepare yourself to

happen. You can only prepare yourself to respond. Uh and that's what

respond. Uh and that's what observability is.

>> And how long did you spend uh building that out at B?

>> I worked on observability at Brex for about a year. Uh in total, I worked at Brex for about two and a half years. The

main things that we did while we were on that observability team was setting up auto instrumentation. So all of every

auto instrumentation. So all of every microser that gets created uh automatically receives a bunch of metrics and traces and logs. Um

installing all the infrastructure that's responsible for capturing and forwarding that information to our observability systems. setting up tools like data dog and configuring them like I went uh I mean data dog is like hundreds of

modules but I feel like I've explored every single one and every knob and configuration option and and tuned it appropriately for for the team at BS uh

and then now have done that at a couple different companies. Um and other things

different companies. Um and other things like making sure that every service has uh like a dashboard that covers all of the key metrics and um and basic monitors. Yeah.

monitors. Yeah.

>> And driving uh SLO and SLI adoption which is a little bit um more that's some observability lingo that is more common in the the enterprise and S sur.

But basically making sure that every team knows how to use observability tools and is measuring their services.

>> And talk about your decision to ultimately leave Brex and start your own company. Yeah, honestly I feel like I'd

company. Yeah, honestly I feel like I'd been Leighton for a long time. I I

started my career as a uh through a web development boot camp and that boot camp was here in San Francisco. I grew up in North Carolina, so pretty far cry from like Silicon Valley startup tech culture. And while I was at this boot

culture. And while I was at this boot camp, everyone I knew was reading Hacker News and uh wanted to work at the hot YC startup. It was like Stripe and Gusto

startup. It was like Stripe and Gusto and uh Instacart at the time. Uh, and it was just an amazing experience for me and it it made me really want to work in startups and specifically to do my own

YC ventureback tech startup. So, from

the very beginning of my career, like that had been my long-term goal. While I

was working at Brex and I was living in New York with my roommate uh who was also an early Brex team member, he and I had relocated to New York together with Brex from San Francisco to help start this New York office. But the the

pandemic happened and so we got stuck in New York with like a two-year lease. And

of course like what do you what do two like software engineers do like when they have a lot of free time and nothing going on. So we started to talk about

going on. So we started to talk about startup ideas and felt that we had a really special team and wanted to do something together and uh applied for YC and that was uh I guess the rest is history.

>> Yeah. Um talk a little bit about how you came up with the idea that you originally applied with.

>> My first company was called Opkit. We

went through YC summer 21 and which was one of the co badges and what opkit was was a voice AI for a healthcare company.

So we build LLM based voice agents to automate calls to insurance companies for things like uh eligibility which is basically when the the provider tries to

determine whether you have coverage or not for your your procedure and for uh uh prior authorization which is another hoop that insurance companies make you jump through to get certain procedures.

uh and also uh to do uh claim to check on status of of claims that have been submitted. Um it's a pretty esoteric

submitted. Um it's a pretty esoteric field. It was a very big big field but

field. It was a very big big field but in a far cry from anything I had done previous.

>> Yeah. Why did you decide to work on that?

>> Yeah, it's I was well I guess to start with my my dad was a doctor growing up.

>> Um so I had a little bit of a lens of like you know if if I know if what I know is like just software engineering and tech startups and you know I need to have an idea that's like out in the real

world, right? like that that impacts

world, right? like that that impacts real businesses, not like just tech businesses. So, the only field that I

businesses. So, the only field that I really knew anything about outside of um uh technology was was healthcare. And I

felt like I had access to my dad who's a subject matter expert and to his practice and his uh his colleagues and I could go interview the staff and the the administrators there. Um, so it felt

administrators there. Um, so it felt like an opening and meanwhile like I was coming from a lens of having worked at Brex and having been very interested in fintech during fint's like real rise

from like during the second half of the 2010s and uh was thinking about like what's next for fintech. You know it's seems like we've done a lot of like consumer fintech and now we have like the Brexes of the world, the Brexes and

the Mercuries. Uh maybe verticalized

the Mercuries. Uh maybe verticalized fintech would be what's next. And so I thought why not like healthcare seems like a big vertical like there's a lot

of money moving there. Um and in retrospect I think uh OPKIT was kind of like an MBA case study approach to to picking a company or picking an idea. It

wasn't based on personal experience or insight or uh like or passion candidly.

It was based on this um this real desire to start something and uh and you know grasping basically for for whatever I think I wherever there was an opportunity.

>> Yeah.

>> Did you ever consider moving outside of healthcare or for you know the you spent years working on opkit?

>> Yeah. Yeah. We

>> was it always like this is a healthcare company and we must stay within healthare.

>> Yeah we you know I regret not evaluating that like fundamental condition more carefully. Um, I mean actually I don't

carefully. Um, I mean actually I don't have a ton of regrets because I am here where I am today and like those there were a lot of hard lessons learned from Opkit, but now Suzabi who gets to

benefit from all of them. But we went in like with a healthcare idea and I you my my co-founder Justin and I love working together and we felt like we were learning a lot and making some progress

slow and steady progress um and peeling back layers of the healthcare ecosystem and learning about new problems within the space. So, we we enjoyed it, but I

the space. So, we we enjoyed it, but I don't think that it was the right thing for us to be working on. And um one thing that I wish we had thought more about is like whether this is really playing to our strengths.

>> Um and I think that's like a great piece of advice for for YC founders and founders in general is like look for your personal expertise or um or or build based something something based on

your prior experience. You probably have more prior experience than um than you think and there probably more openings there than you realize. You don't need to build a business in some other field

just because it feels like whatever you've been doing is not real.

>> Yeah, we tend to see that a lot. People

that have a lot of experience in an area for you is you know observability and even in fintech you probably had a lot of fintech experience much more than than other uh people would

>> and then explicitly saying I don't want to do that because I either I know too much about it so I know you know all the problems or what's going to be difficult about it. um or I'm kind of burned out

about it. um or I'm kind of burned out on it. Yeah. And so I'm gonna go and do

on it. Yeah. And so I'm gonna go and do something that I've never done before and I don't have the the depth of experience or insights on. Was there a moment when you were building Opkit >> maybe in hindsight looking back where

you're like I should have known at this moment that this was not the right thing for us?

>> I think was funny it was like we were definitely not the right team to start a healthcare fintech company or healthcare company when we started but progressively we became that team. Mhm.

>> So, ironically, like if I had if I if Suzabi were a different kind of company, it could be a healthcare or health tech company because we have now four years of hardearned experience in that space.

And at some point, it was like, oh, we've got one year of experience in the space and we're like know more than anyone we talked to. Um, and I guess this is the definition of this uncost

fallacy. But uh there were there were

fallacy. But uh there were there were times when we especially during YC which was at the very beginning of our company which really kind of like kicked us out of the out of the nest so to some extent

um where we evaluated it but we I don't think we went deep enough about that or really reckoned with like what it would look like for us to spend the next 10 years of our life working on a healthcare or health tech company. Um

yeah we should have thought harder about that.

>> Yeah. Well, it's like the curse of the second time founder a lot of times is [clears throat] coming up with the idea to work on because you know too much.

And one of I mean you're describing naive of jumping into this space that you knew nothing about and trying to learn as quickly as you can. But

sometimes that's what's needed too just to be able to >> Yeah, I I think that's true. I mean I think that if you're especially if you're like a real young person and you already want to get started like you can be an expert at anything but you have to

be prepared to put a couple of years of experience in. um to to learn the ropes,

experience in. um to to learn the ropes, to ramp up, to build a network, um to gain trust with with people in the space >> cuz um those things are required. I

think they're preconditions for success.

But if you have some experience, like it doesn't need to be hard. Like you can just trade on the experience that you've already gained thus far. And for Suzabi, I, you know, if everything about OPKIT

was out of alignment with who I am and my background and my experience, my passion with Suzabi, like the first thing I wanted to do was to align everything with who I am. And so I was

like, I'm going to build a tool for people like me um based on my personal experience. Like it's going to be an

experience. Like it's going to be an observability thing. It's going to be a

observability thing. It's going to be a developer tool. I'm going to sell it to

developer tool. I'm going to sell it to early and growth stage tech startups, which is like the only companies ever I've ever worked at. Um, and I'm going to name it after um, Mobile Suit Gundam,

which is a 1970s 80s era sci-fi anime, which I love. So, I was like, this is a symbolic act about making sabi um, in alignment with who I am.

>> Yeah.

>> And, uh, that's probably the most important thing that we most important mistake I think we made with with HP.

>> Yeah. Yeah. Talk about that maybe like uh, the tail end of the OPKit journey and some of the lessons that you learned there and then what brought you back to starting another company. um and

deciding [clears throat] to work on this.

>> I guess to catch people up on Opkit, we were working for about two-ish years and we had built what's called a revenue cycle management software company where we were basically helping medical practices uh check patients insurance

when they come in um keep that information on file and then prepare and submit claims to insurance companies. We

had built kind of a traditional SAS tool for this. Um, LLMs obviously happened in

for this. Um, LLMs obviously happened in that time and one one of the things we learned while working on Opkit is that there's a lot of operations that healthcare providers can only do over the phone with insurance companies and

that's we can maybe that's by design maybe that's not uh and so we had built a call center in the Philippines of people who are calling insurance companies uh to support our the rest of

our product. Um, and we started using

our product. Um, and we started using LLMs to to do quality assurance on those calls and to do data entry and data extraction from the call transcripts and then we built an LLM voice agent. So I I

think we were one of the first teams to actually build and commercialize an LLM based voice agent in healthcare.

>> Um, it was very early. It was very hard.

Uh, I think we really enjoyed the engineering challenge more than anything else which probably points to to what we should have been doing.

>> Yeah. And we did that pivot in our last or in our second year at OPC. Um and so then our we had about a year worth of runway left to build and commercialize

that solution, basically retool the company, reframe it, and then uh and go out and try to raise the seed extension to see if we can kind of keep things going and got to the point where we had about six more months left of runway. We

had prepared all of our materials. We

had launched the products. Uh went out to fund raise. some of our early conversations were were not that exciting. Um kind of didn't seem like

exciting. Um kind of didn't seem like investors were super super interested and that led us to reconsider whether this was the right thing for us to be doing. So

doing. So >> um our decision was that it was not and there's still plenty of time for us to go do something better.

>> Mh.

>> So we then started to seek out acquirers and talked to a lot of growth stage healthcare companies and growth stage fintech companies and that to be honest that felt like more of the same. you

know, we'd be we'd be in a larger organization doing some of the working on some of the same problems we've already been working on.

>> Uh, and then we talked to one AI sales tech company called 11X, which is based here in San Francisco. Um, that was growing super fast. They were building a voice agent. We we knew their CTO from

voice agent. We we knew their CTO from from Brex >> and it seemed like uh a much more exciting place for us to be. We wanted

to get closer to to AI and so we decided to join 11X.

>> Very cool. And yeah, talk about the decision to leave that and then start Sazabi again. And

Sazabi again. And >> I mean, 11X was amazing and and uh I'm really proud of the product we built there and the team we our our team came in and did a lot of great engineering

work there. But uh first thing we did

work there. But uh first thing we did was rebuild their AI SDR product, their sales rep. And that was probably like a

sales rep. And that was probably like a three to four monthl long project of you know building it from scratch uh cutting over from the old platform to the new platform and and scaling it and kind of

getting it to steady state. And in month like five where most of that work had been done. We're now in sort of

been done. We're now in sort of maintenance mode. And that's like okay

maintenance mode. And that's like okay well I've now set up data dog again.

I've set up all of the observability tools and CI/CD tools that always set up. And because I'm tech lead for this

up. And because I'm tech lead for this project, anytime something goes wrong, like I get a Slack message or someone like a a go to market person comes and like taps on my shoulder. Um, so now I'm

like the on call guy >> and I found myself we had we're building a futuristic AI product using futuristic AI coding tools and then I would go to debug it and it was the same painful

manual experience that I've had for my entire career. Uh and so it just it it

entire career. Uh and so it just it it was painfully clear to me that uh we were going to do to uh observability what was already being done to uh like

code generation or or or the the act of creating new code. Mhm.

>> Uh and I also realized, wait a second, like this is like the perfect company for me, right? Like it's it it's completely aligned with my interests, my

experience, my combination of experience in and now AI and uh and infrastructure and dev tools and observability. And you

know, I'm a I'm I I've already been a founder, so I kind of it's not it wouldn't be a scary new thing. Like I

know how to fundraise. I know how to build a team. Uh, I know how to do a big launch. I know how to do press. Um, so

launch. I know how to do press. Um, so

all of the I I felt like I had all of the right ingredients to do this company that this was like the company I was born to to build.

>> Yeah. Talk about anything that you specifically want to do differently with this company based on lessons that you learned from building Opkit.

>> Yeah. I mean, the big one was like build something I know. uh leverage my personal experience, play to my strengths, call it sabi because it should be uh it should be a

representation of who I am. Um, another

one is that I thought it should be fun.

And I think as fun as OPKIT was like I I loved working with my co-founder, my best friends. I love going through YC.

best friends. I love going through YC.

Healthcare was like intellectually rewarding and and interesting and um there were a lot of new experiences which were which was which was great. I

can't say that it was like fun, >> you know, like we were pushing that boulder and the boulder never really, they tell you like the boulder, you get over the hill and the boulder starts to roll. Like it never really rolled for us

roll. Like it never really rolled for us and it was really hard. Um, so my decision to start this hobby was like when I start this new company, it's going to be fun.

>> Mhm. Um, and so I I I think that uh calling it something that I I love and and building in a space that I love and working with u frankly like customers and and other developers that I would be

grabbing beers with anyways if I wasn't uh doing this if they weren't my customers >> uh was another thing another thing that I wanted to do to make it feel like like a better time.

>> Yep. Yep. Talk about your future vision for Sasabi. Where's it going 5 to 10

for Sasabi. Where's it going 5 to 10 years from now? Well, our our mission is to become the default observability tool for all companies uh in what we call the AI era which I would say is um probably

starts with the agentic like the year of agents in 2025 and forwards.

>> Uh our vision is to create this world of self-healing software where software um improves itself without human intervention or direction. And uh I

think you one thing that I that I remark on or reflect on is the fact like companies like cursor are automating this part of the software development role which is like creating new features

and apps and that's obviously like a big part of the job and software engineering is like a trillion dollar industry globally. So right like big opportunity

globally. So right like big opportunity curs is a big company >> but a much bigger part of my job as a developer is maintaining software that's already been written and I think that is

the opportunity for sabi that's what we're focused on. So um I I think we definitely have a the chance to be like a really incredible and generational company um building what we're building.

>> Yeah. Amazing. Talk about the decision to come back and and do YC again for a second time.

>> Yeah. This one is interesting. I feel

like there's like a lot of reasons not to, right? It's like, uh, I've already

to, right? It's like, uh, I've already done YC. I'm already a part of the

done YC. I'm already a part of the network. You know, I've already got

network. You know, I've already got access to book B bookface. Um, you know, it's all my resume, which I feel like that's what a lot of people want.

>> So, it's a little counterintuitive. Um,

I guess from a business perspective, the first thing that comes to mind is that YC is an accelerator and uh we need to accelerate like SABI needs to accelerate. Uh, our opportunity is here

accelerate. Uh, our opportunity is here today. It like will not be here forever.

today. It like will not be here forever.

there are other companies that will try to do it and uh I don't want to waste any time like it feels like very ephemeral to me. So I I want my team to move fast. I think YC will help us move

move fast. I think YC will help us move faster. Um another thing is kind of um

faster. Um another thing is kind of um culturally I I want like to establish a culture at Suzabi that is kind of based on some of the or is imbued with some of

the YC values. Like YC will create like it creates a deadline for us very early.

It has many there are many smaller deadlines along the way. So, we just have to get used to this uh this cadence of shipping quickly and um YC also pushes you to get to market super fast, which I don't well we have a team of

engineers, right? We're like eight

engineers, right? We're like eight engineers or something. So, yeah, it's it would be very easy for us to just build forever and not commercialize. So,

>> I want that. Um

and I I guess on a the last note related to um from a business perspective is get distribution and go to market. Um, and

this is like a little more tactical, but you know, every YC company is a software company. Every software company has an

company. Every software company has an observability solution. Suzi should be

observability solution. Suzi should be that solution. Um, I'll be following a

that solution. Um, I'll be following a tradition of great YC companies like Bracks and Deal and Ripling that have sold into uh their batchmates really successfully. Uh, and I I think that

successfully. Uh, and I I think that Sazabi can do the same thing. So, I want to use that as an opportunity.

>> Yeah. Yeah.

>> Um then on a personal level, my first YC experience was uh was remote. Uh we were one of the co batches. So really

different experience. I mean I'm here in this space today that I've actually I've never been in this building before. Uh

which I think is like points to the fact that I have not had like the full experience and uh it's been a dream for a long time. So I I want I want to uh I want to stand on the stage at demo day

and and and actually have that experience and and make real connections with my batchmates. Um that happen here in person.

>> What's something you wish you knew at the beginning of this journey? you've

you've been through the arc of starting one and >> which beginning are we talking >> exiting exiting it and starting a new one and um maybe if there was something that uh you could go back and tell yourself at the beginning of uh the

OPKIT journey your first time going around during YC what what is the advice you would give yourself?

>> I wouldn't want to give any advice that would actually change the outcome because I think I'm building the the perfect company today. Um, and I think all of the years of like eating glass with Opkit, like that's like my Glen GL

Glen Gary, Glenn Ross period, right?

Where I just like knocking on providers doors and they're like don't want to take my meeting. And um, we built a lot of grit and learned a lot about like how to build a startup under tough

circumstances. U, so I'm really grateful

circumstances. U, so I'm really grateful for those lessons and would not give them away.

Something that I might tell myself or maybe just remind myself is that startups are, you know, a lot of people perceive startups to be short and

fast, but actually we are in a long-term game. It's like a long horizon game.

game. It's like a long horizon game.

>> And the lessons I learned from Opkit, the relationships I built uh with investors, with customers, with other engineers, like I still keep up with my batchmates. Um the you know I I I've

batchmates. Um the you know I I I've many of my batchmates are starting other companies that I could sell into or um that they I could potentially recruit them. Like these are relationships that

them. Like these are relationships that we you build over a long period of time and uh they compound. And so it's it's good to remember remember that be

mindful of it. Uh have integrity be good to everyone you work with because you never know like five years from now you might be asking them for money. Um, so

yeah, I would I think that's a good uh good tip. Probably

good tip. Probably >> for anybody that's watching, talk about um hiring and the ideal engineers to come and work at Sisavi.

>> We are definitely hiring. Uh we're

hiring in a lot of different roles. I

would say that the ideal candidates are uh they're high agency. They learn quickly. They they

agency. They learn quickly. They they

love tools. That doesn't need to be dev tools specifically, but just tools like they kind of geek out on the the saw, so to speak, like the thing that makes you helps you do the thing. Former founders

are great people. I mean, former founders just like have to figure things out, you know? It's and and uh they know what it's like to just do hard work, to um to put in long hours or to do things

that are unsexy.

Uh they're also very flexible. And I

think right now with AI, we never we don't really know what our jobs are going to look like or what the what the org structure in the different departments are going to look like two years from now. So we'll we need people

who are flexible and self starters.

>> Uh on a more practical level like we're looking to basically hire software engineers in a lot of different roles.

So um data and databases and infrastructure are hugely important to Sabi. We build our own log ingestion and

Sabi. We build our own log ingestion and storage system. It's one of the things

storage system. It's one of the things that sets us apart from a lot of other observability tools. And so uh we need

observability tools. And so uh we need to have best-in-class infrastructure and uh expertise at the database level or the storage level. Um we need full stack product engineers of course uh and we

also need like front end and design engineers. So people who I like to say

engineers. So people who I like to say that we're building the linear of observability like it's going to look and feel amazing. Um because you know if you look at data dog it does not feel

that way. Um, so I want to I want to

that way. Um, so I want to I want to hire engineers who have who like appreciate aesthetics and design and um and attention to detail and so that that's where the front end and design comes into play.

>> Amazing.

>> Well, Sherwood, thank you so much for joining. Um, super excited to work with

joining. Um, super excited to work with you on Sasabi as well. Uh, I think you are going to build uh a massive generational company because you're building something that you know a lot

about and that you're passionate about and that you have deep insights in. And

I'm so glad you came back home [laughter] to the thing.

>> Yeah. Thanks for finding me.

>> Yeah. That you know, you know, you know so well and really is the space and the idea and the business that you are the exact right person to be building.

>> Yeah. I hope that um I hope that other founders can kind of learn from my my story and and find whatever they're like uh I've heard it referred to as a tombstone company. So I want other

tombstone company. So I want other developer or other founders to find their tombstone company. Yeah.

>> Um and to come do it here at YC.

>> Yeah. Amazing. So thanks for joining.

>> Cool. Thank you.

>> [music] [music]