Anish Dhar grew up in the Bay Area, but now is located in New York. He felt lucky to be surrounded by technology, being in the Bay Area and having his Dad as a software engineer. His earliest exposure to tech was hacking his Wii - and at that point he was hooked. He eventually joined Uber and experienced many of the problems he is solving today. Outside of tech, he enjoys tennis and playing piano. He loves making music and attending shows to hear other artists, in particular EDM.While he was at Uber, Anish noticed that the company was a prime example of microservices gone wrong. Developers were going outside of standards building services, not documenting them properly. He realized that every company he talked to had the problem of service cataloguing, and he felt confident to apply to take the challenge on and apply to YC.This is the creation story of Cortex.SponsorsCacheFlyClearQueryKiteworksLinkshttps://www.cortex.io/https://www.linkedin.com/in/anishdhar/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
On-prem infrastructure is a requirement for a lot of large enterprises because the way Cortex works is we integrate with a lot of different tooling. For example, we need to connect with your GitHub or GitLab account. And that means we can process the code or read information from those repos, which is important because then you want engineers to be able to access that in the catalog.
First customer was this company called 8x8, and they had very strict security requirements. And so they said, the only way we can use your product is if you give it to us in some sort of on-prem package. But it's completely air-gapped, meaning us at Cortex can't access the product or get any information. It's a lot harder to debug. My name is Anish Dhar, and I'm the co-founder and CEO of Cortex.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as we grow. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve.
Took off the shelf and dusted it off and tried to begin. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on Code Story. I'm your host, Noah Lapart. And today, how Anishtar has built the best internal developer portal, eliminating developer tax and paving paths to production. This episode is sponsored by KiteWorks.
Legacy managed file transfer tools lack proper security, putting sensitive data at risk. With KiteWorks MFT, companies can send automated or ad hoc files in a fully integrated, highly secure manner. The solution is FedRAMP moderate authorized by the Department of Defense and has been so since 2017. Step into the future of secure managed file transfer with KiteWorks.
Visit KiteWorks.com to get started. This episode is sponsored by ClearQuery. ClearQuery is the analytics for humans platform. With their full suite of features, you can go from data ingestion to automated insights seamlessly. With Ask ClearQuery, you can find valuable insights into your data using plain English. Don't miss the opportunity to simplify your data analytics with ClearQuery.
Get started today at clearquery.io slash code story. Anishtar grew up in the Bay Area, but now is located in New York. He felt lucky to be surrounded by technology, being in the Bay Area and having his dad as a software engineer. His earliest exposure to tech was hacking his Wii, and at that point he was hooked. He eventually joined Uber and experienced many of the problems he is solving today.
But outside of tech, he enjoys tennis and playing piano. He loves making music and attending shows to hear other artists, in particular EDM. While he was at Uber, Anish noticed that the company was a prime example of microservices gone wrong. Developers were going outside of standards, building services, not documenting them properly.
He realized that every company he talked to had the same problem of service cataloging, and he felt confident to take the challenge on and apply to YC. This is the creation story of Cortex.
So Cortex is an internal developer portal that tracks internal services, helps you understand the quality of them, and then also drives this consistent developer experience by consolidating internal tools and workflows. The idea for Cortex really came from my time at Uber. Uber is the classic case of Microsoft. This has gone wrong.
There were 100 services on my team when I started, and that ballooned to over 3,000. And what that led to was this incredible impact on developer productivity in a really negative way. Engineers will write services named after TV shows and they'll leave the company and then documentation for that service will be scattered across seven to 10 different tools.
And so when something breaks, it's practically impossible to triage. And you're often just pinging in Slack, asking who owns the service, which obviously adds time to the resolution MTTR. I saw that this happened frequently across the company.
And not just with incident management, even with new engineers who joined, it was very difficult to get them all the context they need to start being productive. And so I was talking with two close friends of mine. One was an engineer at Twilio and the other at a smaller startup called LendUp. And I was asking them how their company solved this. And the answer was, it was the same at Uber.
It was spreadsheets and information living in people's head. That made us realize that if a company as big as Uber hasn't solved this and a company as small as LendUp, which had around 100 engineers, hasn't solved it, there's probably something here in terms of actually building a product that companies can use to catalog their services and understand ownership.
And so we did a bunch of research in the market. We emailed a bunch of large companies like Atlassian to figure out how they saw this problem. And the answer we heard was that they were forced to build an internal tool.
And when we would speak to the owners of these internal tools, they would often tell us, say, this is the most popular internal tool within the company because it tracks your services. It can help with a lot of operational reviews. But we wouldn't have built it if there was actually an available service that had been created.
And so it just gave us the confidence we needed to quit our jobs, start the company. We applied to Y Combinator in the Winter 20 batch. We got accepted. And yeah, we were off to the races from there.
Tell me about the MVP. So that first version of the product you built, how long did it take to build and what sort of tools did you use to bring it to life?
The first version of the product was really just a microservice catalog. And it was basically you could import a set of services inside of the product and tag it with ownership. And then we would have five or six different integrations. So, for example, with PagDuty, so you could see, hey, who's on call for the service? And we built the product pretty quickly.
It was built on React and Java on the back end.
The goal of the MVP really was to validate this thesis that we had where we thought that essentially it's very difficult to understand what services exist in the company and having a catalog of those services can help with things like incident management or looking up ownership or just having this single pane of glass to find all of the data on your services.
What was interesting, though, about the MVP was we built it quickly. We had it while we were in Y Combinator. We kept iterating on it. We would get a lot of demos with people who understood the problem inherently, because when you speak about it with an engineer, universally, every engineer has experienced this pain of not understanding what services are out there and what exists.
And so we would get these demos, but it would never really translate to a sale. And so actually, it was pretty difficult, I'd say, the first year of the company, because We had this MVP. We knew that it was a problem because of our engineering backgrounds, but there was something missing there.
And it took the market maturing and our second iteration of the product with this added capability called scorecards to really hit this emotional pain that led to people buying Cortex. And so that was an interesting learning that we had.
Stay in that era for a minute. You know, with any MVP, you got to build things with certain trade-offs in mind. You got to make certain decisions and trade-offs, right? You kind of touched it in a high level.
Maybe dig into one or two of around, you know, feature cut or approach or technical debt acceptance or, you know, building that MVP to just prove that the model is going to work, prove that the problem is there to solve. Tell me a little bit more about those decisions and trade-offs. And I'm curious about how you coped with those decisions.
There were a bunch, honestly, that were very pivotal in the early days that actually ended up being competitive advantages down the road. One of them, for example, was basically, hey, should we invest early in on-prem? On-prem infrastructure is a requirement for a lot of large enterprises because the way Cortex works is we integrate with a lot of different tooling.
For example, we need to connect with your GitHub or GitLab account. And that means we can process the code or read information from those repos, which is important because then you want engineers to be able to access that in the catalog experience. And so our first customer was this company called 8x8, and they had very strict security requirements.
And so they said, the only way we can use your product is if you give it to us in some sort of on-prem package. So for example, like a helm chart that we can deploy in our own internal AWS account in Kubernetes. But it's completely air-gapped, meaning us at Cortex can't access the product or get any information. It's a lot harder to debug versus obviously just using the SaaS cloud offering.
A lot of the advice we got at that point was don't accept that, like, stick with SaaS. You'll be able to iterate more quickly. You don't know what will happen over time as you have to support now this on-prem and cloud. But we decided to go and invest in on-prem anyway, and we did that very early.
And it proved to be a really strong competitive differentiate for us because as we started working with highly regulated industries like finance or banking, where security becomes even more of a footprint, We just had on-prem ready to go and it was tested. And since our first customer was on-prem, we built a lot of the tooling needed to properly support those kinds of customers from day one.
And today, on-prem is about 30% of our revenue and we still have a lot of customers go with SaaS. It's always ready as an option. Another big tradeoff that we had to make in the early days was whether we should support open source or not. And obviously, that's like a big decision that any dev tool company has to make.
And there's countless examples of successful open source companies in the developer tooling market. Obviously, HashiCorp comes to mind. But interestingly enough, in our market itself, there is a very popular open source project called Backstage that Spotify had open source. And so we had to make a really conscious decision at the beginning of the market.
Do we go open source and adopt a framework like Backstage? Do we stay as closed source? And I remember it was a lot of internal debates on our team about what to do. But ultimately, we decided to stay closed source. And the reason for that is we had a very opinionated view of how this market would develop. And we felt that by owning that experience, we could be opinionated about how...
customers onboard to Cortex, how they use the different parts of the product and just iterate a little bit more quickly. I'm glad we actually did that because I think it just ended up allowing us to move in a more streamlined manner, which I think has helped us win the market overall. This episode is sponsored by Kiteworks.
Legacy managed file transfer tools are dated and lack the security that today's remote workforce demands. Companies that continue relying on outdated technology put their sensitive data at risk. And that's where KiteWorks comes in. KiteWorks MFT is absolutely the most secure MFT on the market today. It has been FedRAMP moderate authorized by the Department of Defense since 2017.
Through FedRAMP, KiteWorks level of security compliance provides a fast route to CMMC compliance, saving customers time, effort, and money. KiteWorks MFT makes it easy for users to send automated or ad hoc files via fully integrated shared folders and email. administrators can manage policies in a unified console and create custom integrations using their API. Did we mention it's secure?
The level of security with KiteWorks solution is rare to find. Step into the future of secure managed file transfer with KiteWorks. Visit KiteWorks.com to get started. That's K-I-T-E-W-O-R-K-S dot com. This episode is sponsored by CashFly. The web is a competitive place, and if your site delivers its content pixelated slow or not at all, well, then you lose. But that's where CashFly comes in.
CashFly delivers rich media content up to 159% faster than other major CDNs. Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits. For over 20 years, Catchfly has held a track record for high-performing, ultra-reliable content delivery.
While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time. For the first time ever, CodeStory listeners can get a 5-terabyte CDN for free. Yep, you heard that right, free. Learn more at CashFly.com slash CodeStory.
That's C-A-C-H-E-F-L-Y dot com slash CodeStory. You've made those decisions. You've got the MVP. You're getting some traction. Tell me about how you progressed and matured the product from there.
And, you know, to wrap that in a box a little bit, what I'm curious about is how you built your roadmap and how you went about deciding, okay, this is the next most important thing to build or to address with Cortex.
So I mentioned that like the MVP was just the catalog experience and it was difficult to get an actual sale from there. And we did a lot of just discovery with prospects and people who said that they were interested but didn't end up buying. What we realized was, hey, look, the catalog, it's great for capturing data. It's great for understanding who owns a service.
But then the question becomes, how do you keep that up to date? The next question naturally after you get the data in the catalog is, okay, what do I do with it? How do I get engineers to care about it?
And the question that actually we came to that a lot of these prospects were trying to solve, which was actually much harder to solve than gathering the data was, how do we get engineers to care about best practices from a reliability or security perspective or operational maturity perspective using the data that's inside of the catalog?
That was just a light bulb moment for us because what we found was there's the developers who look at the catalog, but then there were practitioners within the engineering team like SREs or security engineers who were trying to get developers to follow those best practices, to care about things like production readiness or security standards.
But the way they were doing that were creating these massive spreadsheets that had
all of your services and who owned them basically like what the catalog was but then also is your service have an on-call rotation and the meaning is ethos from datadog and obviously like it's hosted in confluence somewhere developers are not looking at it it's impossible to enforce and then even harder to create that culture and so that led us to building our second product which was scorecards
Scorecards are basically a way to enforce best practices and then drive engineers to essentially follow standards and incentivize them on what does good and great look like in terms of service quality. And we started targeting our demos a lot more to SREs. That's really where we were able to scale out the company, get our first actually meaningful sales.
It was a great from like iteration process to basically finding ultimately product market fit in terms of, hey, what is actually a emotional pain that people are looking to when they buy a developer portal?
I hear you talking about we and us. Tell me about how you built your team. What do you look for in those people to indicate that they're the winning horses to join you?
Culture is super important to myself and my co-founders as well. Obviously, coming from Uber, it was a crash course on how to mess up your culture in a lot of ways. And so I learned a lot in terms of how culture impacts the work that people do and how they feel connected to their work.
And so we're very intentional about, especially like the first 10 people we hired, since we knew that would ultimately set the tone for the characteristics for the rest of the company, the culture that we would build. And so there are a few things that are really important to us. The first is a high degree of self-awareness.
I've always really valued people who are self-aware because not only do they understand their strengths, but they know their weaknesses and can lean on others around them to become stronger. There's also, I think, a high degree of self-awareness leads to people who are more humble. We have no asshole policy, which I think has been great.
And I've always really enjoyed working with people like that, especially when it comes to people in the leadership position. And so that's really maybe the most important trait that we look for. And the second trait is people with a chip on their shoulder.
So maybe it was someone who got passed on for a promotion or someone who worked at a company that didn't maybe realize its full potential, but they're hungry now for that second opportunity to just join a rocket ship that is going to win. It really creates this incredible energy when you talk to people like that. Even when you're in a Zoom meeting, but everyone is just so motivated to win.
I think it just creates a dynamic where it feels like you can't even lose. And the momentum, When you do win, just adds to each other. And so I think those two traits have the most important from like the early days and how we tried to hire people.
Hello. Welcome to the data analytics club. Do you know the password? No, I didn't know there was one. Do you know how to code? No. Do you know how to query data? Like ask a question? I guess not. Hmm. I see. Then you can't be in this club. Sorry. Goodbye. Don't be left out of the analytics club. ClearQuery is the analytics for humans platform.
With their full suite of features, you can go from data ingestion to automated insights seamlessly. ClearQuery provides you with the information you need without requiring you to do the heavy lifting. Their Ask ClearQuery feature allows you to ask questions in plain English, helping you find relationships and connections in your data that may have previously gone unnoticed.
You can even visualize your data with presentation mode, taking your data storytelling to the next level. Pricing is based on storage, not licenses, and that ensures that you get the most bang for your buck. Don't miss the opportunity to simplify data analytics, your data analytics, with ClearQuery. Get started today at clearquery.io slash codestory. This episode is sponsored by CashFly.
The web is a competitive place, and if your site delivers its content pixelated, slow, or not at all, well, then you lose. But that's where CashFly comes in. CashFly delivers rich media content up to 159% faster than other major CDNs. Through ultra-low latency streaming, lightning-fast gaming, and optimized mobile content, the company offers a variety of benefits.
For over 20 years, CatchFly has held a track record for high performing, ultra reliable content delivery. While competitors call themselves fast or use cute animal names, only CashFly holds the record of being the fastest and serves customers like Adobe, the NFL, or Roblox, where content is created by users and must be delivered in real time.
For the first time ever, CodeStory listeners can get a 5TB CDN for free. Yep, you heard that right. Free. Learn more at CashFly.com slash CodeStory. That's C-A-C-H-E-F-L-Y dot com slash CodeStory. Okay, let's flip to scalability. And this will be this will be interesting. You have a lot of experience with with big companies, you know, like Uber.
And I'm curious, did you build this to scale efficiently from day one or scale in mind, obviously abstractions and things or has there been any interesting areas where you've had to fight it as you've grown?
A lot of the early adopters of Cortex inherently understood that we were a startup. Obviously, they were buying from a seed state series A company. And so they were a lot more OK with UX quirks or slowness in the product. Like we definitely did not build a product for a large scale from day one.
I think our philosophy from an early engineering perspective was get things out super quickly, keep iterating on them and optimize for figuring out what the customer will use the most.
But then the interesting thing that happened to our market is that the market awareness grew so quickly and so exponentially that suddenly we started working with organizations that, for example, H&R Block is one of our customers. And H&R Block generally is expecting to buy software that just works from day one, that is very reliable, that is very secure.
Versus an organization like SoFi, who is a little bit more tech forward, who took a bet on us very early on. And so what that has meant from an engineering and scalability perspective is we have to like over the past year and a half, there's just been this intense focus on building from day one products that can scale.
And what that means is scale not just to what we were initially used to a few years ago, which was like maybe 10,000 to 50,000 services in catalog, to our catalog needs to be able to support up to 10 million, right? And when we connect to your AWS account, we should be able to import everything very quickly. without any hangups or like UX quirks and things like that.
And so that has been a bit of a culture shift, but what's been great is the team has really embraced it and it's changed how we do tech spec reviews and just onboard customers as well. We're very intentional about, hey, Cortex should be able to support any customer at any scale. We were lucky that our market grew like that, where it just naturally grew into more enterprise.
So that enterprise readiness has been a big focus and scalability is a big part of that.
So as you step out on the balcony and you look across all that you've built thus far, what are you most proud of?
I'm most proud of the team that we've hired. I know I spoke a lot about culture, but culture is one of those things that it's hard to quantify. Being a founder, especially in a remote-person environment, it can be hard to know, is the culture working in a sense? Do people feel connected to the mission of the company?
Are people motivated to work because of the people that work with them on the team? But we have these quarterly off-sites where we actually fly out the entire company to some location and really bond over a week and do in-person working sessions.
And this past one we had in New York, the one thing everyone consistently told me when I asked them for feedback or when I spoke to them was how much they feel connected to this idea that we're building something bigger than any one of us and how excited they are by the market and the potential and this fierce competitiveness to win.
It's really heartwarming to see that that really intentional culture that we built around like the first like 10 to 20 people has permeated itself. And now as we approach 100 people, it's more real than ever. And it's something that people actively talk about. It energizes them. It gets them motivated to work every day.
Okay, let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it.
One of the mistakes that we made early on was, and I think every founder has experienced this, it's like the first time we made a hiring mistake. I think we made that mistake because we had been looking for the specific role for a long time. And when you're recruiting and you keep saying no to people and it's been like six months and the role is still open, it starts to wear on you a bunch.
And suddenly the criteria or like how stringent you were when it came to culture or maybe even like a technical phone screen starts to dip. And I think that happens naturally to a lot of people, especially like a team that's like really different. aggressively trying to recruit.
And so we hired someone who maybe we had said we would have said no to six months ago, just because we needed desperately to fill that role. Within the first three months, it became very that this person wasn't a good fit, but both from a cultural perspective and just the skill set that they had. Which is fine, right? That just happens when you're growing quickly.
But I think the downside of that was when you have a bunch of A players who are operating at the highest level, they immediately can tell when there's, let's call it a B player in the room. It really demotivates, I think, a lot of people because they're putting their 150% in and suddenly there's this person who's not in the same boat. And I think it really is a big distraction.
And so that was a big learning lesson for us. It was really important for me personally. And it's really changed the way that we recruit as well. The time to fill a position is not important, not even like a factor when it comes to these types of things. Like we have to find the best person for the role. And so that was a really important learning lesson early on.
So this will be fun. Tell me what the future looks like for Cortex, the product, of course, but also for your team.
When we raised our Series B, we had this thesis that every company is a software company, and I think everyone can agree to that. But I think what has happened to software has also become incredibly complex. And it starts, honestly, really early on in a company's days. Even when we had 20, 30 engineers and were building, ironically, on a monolith, there were still so many things that...
went into the software, right? It's not just your services, but all the infrastructure, databases, pipelines, even the third-party vendors you're using, all of these different components have owners, they have information about them that just lives in people's heads.
And I think for the longest time, people tried using Jira and Confluence as like a system of record to understand all this information, but talk to any engineer, those tools weren't built to really represent the software of a company. And so I think
There's this really amazing opportunity for Cortex to be that system worker for engineering in a meaningful way, because for us, the atomic unit of our software is the service. And the service can be represented as an EC2 instance. It can be a microservice. It can be a third party vendor. But all that information can be cataloged, scored and improved upon inside of the product.
And so in the same way a sales team, when they're scaling, they buy Salesforce, it comes with all of the tools you need to scale your team. That's where we really want to build with Cortex is this platform that comes with all of the tools you need to scale your engineering team from five to 50,000 and be a true partner to
Not just the developer inside of the organization who needs to understand their services or with incident management or building new services, but even the CTO who is trying to understand where the areas of risk in the business from a reliability, security, operational maturity perspective. How do I actually increase developer productivity?
Developers only really spend 30 to 40% of their time coding and the rest of it, it's just like asking questions, trying to find information, dealing with incidents. How do we reduce that amount of time and give more time back to actually coding and building software for the business? I think that's the ultimate goal and vision for the company.
From the team perspective, I think we've been really lucky that we were able to grow different parts of the company. We're fully remote, but what's also exciting is we've started expanding internationally as well. We hired our first strategic account executive in London, which is going really well.
So I think next year, you can definitely expect us to have more of a presence in Europe and Australia and different parts of the world, which should be really cool.
Let's switch to you, Anish. Who influences the way that you work? Name a person or many persons or something you look up to and why.
Like very early on, it was my dad, just seeing him work as a software engineer, seeing him grow in his career was super inspiring. And then when I got to high school, it was definitely Mark Zuckerberg.
I was just enamored with this idea that someone who was only 19, 20 years old was building what I felt was the most important company in the entire world and doing it 15 miles away from where I lived in San Jose. I think that was incredibly inspiring and incredibly motivating for me, even when I was like 13.
Just seeing the way that he has expanded the vision and the mission of the company, despite all of the naysayers, he truly is one of the most incredible founders of our generation and still has a lot of years left to continue defining Meta. So yeah, from a very early age, I think it was very inspiring to see what he's been doing.
Last question, Anish. So you're getting on a plane and sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world. And can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
When you hear other founders talk about how hard it is starting a company, obviously you internalize it and that starting a company is difficult. But I think it's impossible to explain unless you've truly experienced it. I call it like a shared pain that every founder has experienced with their co-founders where it's like the highs are like the best feeling in the world.
But then there are so many lows. And for us, that meant people like that first year and a half of just not being able to sell the product to anyone and people telling us to pivot. And we were just like, no way. I think the biggest piece of advice I'd give is just that resiliency and staying the course.
And I think having this determination that you're going to figure it out, even when inevitably there are those lows, you just truly have to just have this determination that you're going to figure it out. And so I think it's just... Having those expectations that this is normal, like it's supposed to be like a roller coaster of emotions, even like on a day-to-day basis.
But the output of that is like bringing something into the world that people use and find value in is makes it all worth it.
That's fantastic advice. Well, Anish, thank you for being on the show today. And thank you for telling the creation story of Cortex. Thank you so much for having me. And this concludes another chapter of CodeStory. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review.
Both things help us out tremendously. And thanks again for listening.