Brendan: Hello, and welcome to PodRocket. I'm Brendan, I'm your host and I'm on the engineering team here at LogRocket. Joining me today is Ankit Jain. Ankit is the co-founder and CEO of Aviator. Welcome to the Pod, it's great to have you. Ankit Jain: Thank you. Thanks Brendan for inviting me. I'm really excited to be here. Brendan: Great. Well, why don't you start by telling us a little bit about yourself? Who are you? What's your history? And how did you end up as a founder of a dev tool startup? Ankit Jain: Absolutely. I would love to. So, I'm a software engineer by trade. I grew up in New Delhi. I came to U.S to join Google a decade ago. And since then I've been mostly working as a software engineer. I worked at Google for a few years and went to startups. And in startups, I've led engineering and a lot of high growth companies, including Homejoy, Shippo and Sunshine. I've had about 15 years of engineering career working in all front-end, all the way to writing CSS all the way to doing systems design and building open [inaudible 00:01:18] search. Full stack in real terms. Brendan: So, it sounds like you've now done both ends of the spectrum. You've been at the very largest tech companies and at startups. What do you feel are the things you've taken away most from being in very large and very small environments? Ankit Jain: There's no doubt that in small startups, you get to do a lot more work and have ownership. But I would say since I've started working in startups in the last 10 years, my quality of engineering has certainly gone down. I was probably a lot better engineer when I was at Google. I learned a lot from really smart people. And I think what I've enjoyed in startups is certainly the velocity that you get in terms of development and the impact that you can show in small teams. In large companies, I have cherished working with really smart engineers, but it feels, again, things move slowly compared to startups. Brendan: And is this your first time as a founder or executive at a company? Ankit Jain: To some degree, yes. I have dabbled with some ideas back in 2015 when I was a young entrepreneur, but I definitely learned a lot during that time. I tried a few ideas and really understood what it means to have product market fit. And also, I learned a lot about what it means to do things that solve your own problems. Brendan: What was it that finally convinced you to take the leap and found Aviator and actually start a company? Ankit Jain: Since I've left Google, I've always pondered on working in startups and actually starting my own company at some point. But I also knew that I have to have a very strong, compelling idea that I strongly believe in before I go and do it. After working about almost a decade in startups, I realized after, that in every company I'm actually building same things. Companies like Google and Facebook have built these amazing productivity teams internally, and this is something which I go and have to build everywhere else in every startup. I can share a little bit about Aviator so that at least the audience have context. Brendan: I was going to say, this is a perfect segue to talk about Aviator and what you're building and what you're working on. So, let's dive in. Tell us what is Aviator and what do you do? Ankit Jain: Aviator is a YC back startup. We started it last year in 2021. It's a developer productivity platform. It connects with your existing toolkit and runs automated workflows. For example, in large teams, it can do automatic merging. It can help you manage your stacking of PRs. We have a CLI for that. You can also manage flaky test. And our philosophy behind building Aviator has been... again, going back to Google and Facebook, companies who spend a lot of time improving engineering productivity for teams. Every other company out there is looking to do the same, but they don't have enough bandwidth to do so. What we are trying to do is essentially provide engineer, developer productivity in a box, and that's what we build Aviator on. Brendan: And maybe implied there, it sounds like also there are pretty similar patterns in how engineers at big companies like Google and Facebook manage their workflows. Is that generally true? For people who have the bandwidth to build these developer tools, are there consistent experiences? Ankit Jain: Yeah, absolutely. In some ways... When we think about developer velocity in a company, in large companies, how you think about building a feature given a spec, how you think about building a feature and deploy that to production. You would imagine most of the time from an outside perspective that you'll be spending most of your time just writing code, but in reality, in large companies, majority of the time you're struggling with collaboration where it's like, "Oh, bills are failing. My tests are not passing and it takes very long time to do code reviews." Everyone deals with that every day. And those are the challenges which I have seen in some of the best companies, how they have really turned around by building some of these tools internally. And what we are doing is democratizing that for the rest of the world. Brendan: That's really exciting. I know you touched on a couple of the different features that you offer, but it would be cool if you talk in more depth about some of the key features that you've built in Aviator and what is it? What does it do? How does it improve the developer experience and what would I get out of using it as an engineer at say, LogRocket, a 30 person engineering team? Ankit Jain: Sure. Absolutely. Some of the tools that... I think maybe even before we go into specifics, it's helpful to understand developer productivity space. First let's think about how, again, this term is used in many different ways. We have categorized it in four different... It can be categorized in four different pockets. First one is how you think about onboarding developer and developer setup, developer environments, those kind of things. The second category would be knowledge sharing, debugging. How do people think about... Once you are onboarded, how do you get information about debugging? And the third is collaboration, where it's in a team, how do you think about collaborating with other developers, how long it takes to push out the code. And fourth is typically reliability, which where a lot of companies go around thinking about DORA metrics and how quickly it is to identify issues and resolve them. Our core product is focused around collaboration. Typically, it will not be useful if you are an indie developer working by yourself, but in a team, the challenges are much more complicated and that's the problems we're trying to solve. And typically for a team like LogRocket, yours... Some of the things that could be super helpful is if you... One of the things that you would strongly want to believe it, want to get as a, I would, say engineering principle is having very stable bills. Because unless you have stable bills, you cannot really think about having strong, very high velocity for the team. To have stable bills you need to make sure one, your tests are always passing and your bills are always green. These are the things that we've primarily focus on. In terms of our capabilities today, we have the automated merging. What our system do in those cases is even for a team of 20, 30 developers, we have a lot of companies with those sizes use our product. What would happen is instead of merging your changes manually, just assign those changes or PRs and GitHub to us. And we would take care of... We become the gatekeeper. We take care of... These are always validated with the latest changes before you merge. The advantages here are, if you have semantic conflicts, let's say two developers are working on the similar code base. If you change method in one place, your CI may still pass, but eventually it may break the bill because you have validated on an older CI. For larger teams now this becomes much more complex problem because now you need to merge 100 to 100, even thousands of changes in a day. And the amount of CI you can run is somewhat limited. You don't want to spend too much time in CI executions. That's where some of our more complex workflows come in. So, that's at least on the merging part. I think the other philosophy is around stacking PRs. And this is something which we have also learned a lot in as evolution of code, especially if you work on bigger features, you would want to make sure you can break them down in more logical constructs so that it's easier for people to review. And that's a philosophy which is very well promoted by Facebook internally, but it's also catching grounds a lot lately. We have provided CLIs as well as some of these automated back-end workflows that makes sure your PRs and stacked branches are always up to date. And last is around managing flaky tests, which is if you have failures in your systems, or if you have unreliable tests, which is passing and failing without any code changes, those are the places which we are able to identify and automatically suppress. These are the three core workflows that we build today. Speaker 3: Enjoying the podcast? Consider hitting that follow button for even more great episodes. Brendan: It sounds like your approach to handling flaky tests is designed to be more framework agnostic and not specific to any language or test suite and more around identifying that connection between what could break the test and what tests are actually breaking. That sounds really hard. How have you approached that? Ankit Jain: This is actually truly a hard problem and we are taking a step by step approach. One, yes, we have built initially a workflow, where, as... Most of the test runners today actually have capabilities to export results as JUnit, including cyberizing, including PIE test. It doesn't have to be just Java test. We actually have built an engine to process those results and provide you with identification of failing test. Now that said, we are also building a little bit more language specific framework where you can also install the plugins in your test runners to not just automatically detect flaky test, but also rerun specific test, which have been detected flaky. It works very well with our back-end systems so we can keep a track of all the flaky tests and this library that you can install can automatically just rerun the flaky test for you. Brendan: One of the things that I would worry about as a developer having flaky tests identified or suppressed is, there's always that story everyone has of the tests that broke in a completely different part of the code base that actually tipped you off to the critical bug in your code. And I'm curious, what feedback from your users has been about this feature? Is it something people are excited to adopt? Is it something people are apprehensive about adopting? Ankit Jain: That's a great question. In fact, we had a big debate on Hacker News as well a few months ago, which was around how people think about flaky test. And yes, in some ways the opinion is that people should not even have flaky test and the more important aspect about it is just detection rather than suppression. That said, what we have learned, especially in larger organizations is even if the flaky test are detected, most cases, what a developer is going to do is comment out that flaky test and then create a JIRA to resolve that. And essentially what we are doing is reducing the human effort involved in managing and tracking that. So our system is also now going to connect with... This is something we are building, it's like, you can connect with your JIRA systems and it was going to, when it's suppress a flaky test, it's also going to create a ticket for it. So essentially those are the places... The way we think about it is many of these things that developers are now, just... Learn to do manually over and over again, we are just reducing that at first and overhead for developers. So that's how we build many of these workflows for them. Brendan: It feels like kind of a pragmatic approach to balancing the trade offs because you're right. At most companies, especially startups, you've got to move fast. You don't have time to chase every single flaky test in the code base most of the time. Ankit Jain: And then everyone is frustrated about the flaky test because then they have to manually rerun them. In fact, we talked to some of the companies who have automatically set up to rerun on every failure, the test 10 times. Which is, okay now you're not only rerunning flaky test, you're just rerunning everything. So there are definitely some optimizations we can do there for saving time. Brendan: Another thing I think... We've actually talked to a couple founders this year about stacked PRs. It's weird that it keeps coming up in the podcast. They're really having a moment right now. I'm curious if you could talk a little bit more, maybe for someone like me, who's spent most of my career at pretty small companies. I do most of my work by making a PR to master and then merging it when I get a thumbs up on it. What are some of the key differences that you get from using a tool like Aviator and stacked PRs that maybe I wouldn't get if I just made a branch and then branched off my branch and went through that, I guess, out of the box to get workflow. Ankit Jain: So a couple of things, I think one of the reasons why we are seeing a little bit increase in startups doing stacked PRs is because there was this product maintained by Facebook called Phabricator and Phabricator got deprecated last year. So I think many of the frustrated developers were like, okay, we need an alternative. And that's where some of these products have come out, and that's one of the reasons we also ended up building because some of our teams we work with, they were like, we need something to replace that. And so to at least compare with existing products, one of the reasons why we would want to use Aviator, stacked PRs, CLIs in back-end is because our core focus has been around build stability and automating merging. And most of the challenges that you have at stacked PRs are around syncing and merging. So essentially imagine that you create, like in your example, let's say you create a PR, let's just say you can define the basic data models and now you're going build up back in API for it. So, you define the data models in one PR and then you extend that and create back-end models for it, right? Then you go back and say, "oh, actually, there is some changes I need to do in the data models." So you go and update your branch with the data models, but now you're following branches are still, right? It doesn't have those changes. So what our system does is essentially... We use GitHub label, so you can assign a GitHub label to it. And it's going to always make sure your branches are up to date and synced. And we have CLIs as well. This is probably fine when you only have a couple of branches, but when people use stacked PRs, they can even have up to 10 or 20 stacked branches. So this essentially becomes a nightmare to keep all these branches up to date and sync. If you are working with multiple PRs or multiple stacked branches. And on top of that, if you are merging, you can merge partial of your stack and rest of the changes get... Essentially, we automatically revisit those changes. So again, it ties very well with our back-end systems around merging and syncing. Brendan: So I guess maybe it's not as much the happy path of I make a PR and another PR of that, and all of them are perfect and there's no changes... Ankit Jain: Unless you're director of engineering, where you're admin super powers and just forge without approval. Brendan: So I think another... You've mentioned working with GitHub and then how you integrate with GitHub a couple times. And I think this is a really interesting question that's kind of at the intersection of product and tech, which is obviously meeting people where they are and getting teams that use GitHub, can have an easy time adopting Aviator and using tools they're comfortable with. But also how do you balance that against the risk that GitHub decides stacked PRS is the next challenge it wants to take on. What are some of the pros and cons you've weighed and tightly integrated with another platform? Ankit Jain: Yeah, absolutely. I think in some ways GitHub has become the default platform for most of the developers. I mean, obviously there are still a lot of developers who use Atlassian and Atlassian's bitbucket and GitLab as well. One of our core responsibilities and one of the core thesis is around integrating with not just GitHub, but all your different tools out there. So GitHub does provide open APIs, but what we build is essentially opinionated workflows. So for instance, the example I was telling you about suppressing flaky test. Those kind of things are tricky for GitHub to build just because they are more of an open platform that expects other people to build things on top of. So in some ways, the way we think about it is GitHub is essentially the layer one of providing source control, providing basic capabilities around code reviews. What we are doing is essentially building an automation layer on top of GitHub, which is essentially... Now you can go in future, if a team decides they want to move from GitHub to GitLab or do Atlassian. Then they can just swap out their source control. At the same time, they can continue maintaining some of these automation workflows. So that's how we think about... It's not a competitive space. It's more about building more abstractions and automations on top of the existing infrastructure. Emily: It's Emily again, producer for PodRocket, and I want to talk to you. Yeah, you. The person who's listening but won't stop talking about your new favorite front-end framework to your friends, even though they don't want to hear about it anymore. Well, I do want to hear about it, because you are really important to us as a listener. So what do you think of PodRocket? What do you like best? What do you absolutely hate? What's the one thing in the entire world that you want to hear about? Edge computing? Weird little component libraries? How to become a productive developer when your WiFi's out? I don't know. And that's the point. If you get in contact with us, you can rant about how we haven't had your favorite dev advocate on or tell us we're doing great, whatever. And if you do, we'll give you a $25 gift card. That's pretty sweet, right? So reach out to us, links are in the description. $25 gift card. Brendan: And so it sounds like there's us, strategic, philosophical difference. You see between the problems that you are trying to solve it, and that GitHub sees itself wanting to solve. Ankit Jain: Exactly. So our thesis is are all around plug & play solutions. If you want to... in some ways we compare many times UX to WhatsApp where if you want to do text messaging... My parents use it and it's very easy to use. But there're so many complex things you can do in it. You can do real time location sharing. You can do file sharing all of those things, which are hidden features. So the way we think about it is very simple plug & play interfaces for people. But if you want to go into advanced mode, we have a lot more configurations and things you can play around with, especially for, as your team grows. Brendan: Yeah. You're right on the verge of also talking about something that I think we think about at PodRocket, which is building a product for other developers to use. And on the one hand, you've got a ton of empathy for your users, because in a way you are your users, we're always in our own product using it. But at the same time, you also have to make sure you're not sort over indexing on your own experience and your own preferences and actually building the thing that your user needs you to give them. I'm curious how you've approached that? How much do you lean on your experience working with these types of systems and how much do you base what you're building on specific customer feedback? Ankit Jain: I mean, this is also a very interesting running debate internally, because many times we also talk about user interfaces. For developer, user interfaces are always very opinionated because in some ways, the many times we have an internal debate it's like, oh, we just provide a configuration file. Users being developers, they will know what to do and they would be very comfortable playing with this. The other end of spectrum is you build interfaces, which is almost... I would even say Slack for instance, most of the complexities are hidden by the developer or for developers, but at the same time, if you want to do more complex things, you can. So you provide a UX experience where it is almost no code you drag and drop something, or you specify some things in form fields and it works. And I think in some ways this is a distinction we have to always think about it as a company building developer tools versus a developer themselves. We have learned is there is no perfect answer. You will find developers in all spectrums. One of the other things we try to do is bridge the gap between a developer and a DevOps person today. And a DevOps person may be very comfortable doing a lot of complex things versus a developer fresh out of school, may not know all the complexities that go behind it. So what we try to do is essentially provide two versions per product, which is like, okay, if you want to just get started, you just connect your GitHub repository and specify two settings and you're done. Versus if you are a team with 1000 developers, you need to figure out, how do you optimize the configurations, turn every knob to make sure you can get the best experience. Brendan: And I think one of the other things that brings to mind is there's kind of a central story here of, like you said, democratizing tools that maybe people in big tech companies, companies that have the resources to build internally, have had access to for a long time, but which have not really permeated down to most of the rest of the Dev market. And one of the questions I always have about this story is, how much of that is those tools being right for companies at just massive scale versus how much of that... Will small teams get the same value out of a tool like this in a product like this, that Google will. Or is there some sort of scaling click you hit where some of these ideas don't scale down? Is that something you've thought about or run into? Ankit Jain: I mean, that's a great question. And in fact, that's something we also think a lot about. Our primary focus has been, we typically say high velocity teams, which is ones who care a lot about engineering productivity, the ones who care a lot about having high... Shipping code fast. And almost every company, at least, well, almost every new generation company wants to ship code fast. And that's where they're trying to spend resources as well as try to figure out what are some of the more newer generation companies are doing. And that has been our core focus. But that said, yes, I think the collaboration challenges that we are solving, it has almost like a exponential graph in some ways, where if you go beyond a certain point, let's say, if you have over a hundred developers, these pinpoints will be so severe that you're like, it's a death by a 1000 cuts. Versus in smaller startups... This happens once in a while. Maybe your bills break twice a week, fine. It's no big deal. Maybe waste two, three hours of developer time. That's about it. But I think if you think about saving 10% of developer time in a team of 100 person, you're essentially saving them 10 developers worth of salary. And that's kind of how we have at least thought about it today. And again, I think at scale, we do expect, as we build more and more complex workflows, we will be able to scale for several thousands of developers over time. I think the other question that you were asking is it going to be equally valuable for startups? I would say today, probably not because it's still something that you only use in teams. It's not something as you use as well as a single developer. But we are also working and building some of these capabilities, for instance, flaky test is a problem which will happen as long as you're writing tests. Now, if your company doesn't believe in writing tests, it may not be useful. So if you're starting as a two person company, probably it's not going to be as helpful. What the challenge we are solving is how do we think about teams which are collaborating. And especially if you think about it, in the last two years, the collaboration and work has changed completely. So most of these companies are also trying to figure out what does it look like going forward? Clearly everyone knows remote work is not going away. So that means, now people need to figure out what does a synchronous collaboration and what does developer velocity, developer productivity in this new world look like? Brendan: Yeah. So you said a little bit about today, but I guess that prompts me to ask what's tomorrow? What's on the roadmap? What sort of features are you working on that you're most excited about? Ankit Jain: Yeah, absolutely. So the way we have thought about it is, it has been our philosophy as a company as we started by building tools, now we have a product which is Aviator that helps you solve bill problems. And we are transitioning that into a platform. The way we think about the platform is, every company has slightly different workflows on how they manage their PRs, manage their work, manage their testing infrastructure, manage CI/CD, all of those things. What we are doing essentially is building a workflow engine, which is essentially, you can come in, create your own workflows on top of. So essentially if... Let's take an example. So we have some teams who are like, oh, we actually don't care as much about breaking bills. We care about being able to merge changes faster. But if it breaks once in a while, we won't waste through which we can do automatic roll backs. So those kind of things, now you can come in, define your own workflows and build on top of our systems to actually take actions. And similarly, you can do different things. Let's say if you're using some sort of a security detection platform or product, which identifies some sort of security vulnerabilities. You can use our workflows to essentially, either automatically create changes to identify and automatically roll back those security issues. Or you can even notify certain people about, like, Hey, this is happening and these are things you can do. So the way we think about it's there's data that lives in all different systems, there's information sitting in your GitHub, in Datadog, or any other developer tool that you're using. You're just bringing essentially, building this engine to take actions on top of it. Brendan: Well, before we go, I also wanted to talk a little bit about the experience you've had of growing Aviator as a company. I know you guys closed your seed around earlier this summer. I think you raised 2.3 million. So congratulations. That's a huge milestone. This is also, I think a interesting time to be starting a company and to be raising money. I think there's been a ton of discussion in tech and VCCircles around the market, the cost of capital, how investors are thinking very differently about what they're looking for from companies, now than they were maybe two or three years ago. I'm curious what your experience was like talking to investors and raising money in this market. Do you feel like it was noticeably harder or different than what you've seen other companies experience in the past? Ankit Jain: I mean, absolutely the difference I would say... So we went to Y Combinator last summer and the difference in investor mindset then versus now is completely different, but at the same. So I think what has happened now is almost every company is forced to think about business metrics and business outcomes. And that's where we differentiated ourselves a lot, because from the beginning, we've actually wanted to create a product that we can also monetize. So from the beginning we used to charge very little, but we always thought about revenues as well, especially given our focus on larger companies and the problems that we are solving for them, those kind of things we have always kept in our mind. At the same time, we do understand we are a startup of ourselves and there are smaller companies who may not have the capacity to pay. So we are still offering free products for smaller teams. And the expectation is somewhat similar to how many of these other companies like Stripe also grew, helps get some people start using our product, build those habits and over time grow with that. So in terms of investors, I think we certainly lucked out quite a lot. We have some of those most prominent investors in the Valley, including Lenny Rachitsky, who runs a very famous product podcast as well and the newsletter. We have Elad Gil who's one of the early investors in Stripe. Then we have some of the other founders from Retool and [inaudible 00:30:21] so some of the developer tools as well. So we've been very lucky and those people also act as our hard mentors as well, so we learn a lot from them. Brendan: Yeah, and I think having the story of who your customer is and what your market is from the beginning, feels like something that maybe was less demanded of startups a few years ago. And now feels like you just need to get in the door, is to have a clear idea of what the business actually is. Ankit Jain: Exactly. Brendan: I guess the other question I'm curious about is what are your plans for this fundraising round? Are you planning to hire? How are you turning this into growth for the business? Ankit Jain: Yeah, absolutely. So we are definitely hiring engineers. So one of the things is the kind of product we are building, almost every engineer we hire comes with a mindset of being a DevOps engineer, because a lot of things that we do requires, in some ways we call it plumbing, which is... We know that data exists in all of these silos. We need to connect and make sense of it. And I think that requires a little bit of DevOps ethos. And we definitely see a lot of people excited about the things we are working on. Because one of the best things about working in developer tools, which you probably also know, Brandon, is if you're solving your own problems, you'll definitely resonate with certain developers who are really excited about it. And that's how we have seen and hired people in our team so far. So we have three engineers in our team all come from speaking, small engineering backgrounds, as well as running their own startups. And they're really excited about solving these problems. And we have also brought in one of the marketing person recently. Brendan: And I guess that also is an interesting thing to think about is when you're finding engineers at an early stage company, it's really challenging, right? You're making a huge bet on each one of these people. And so how do you think about balancing mindset, interest in the product, specific experience with technologies? What do you weigh when you're looking for really early engineers? Ankit Jain: That's a great question. So one of the things that I've actually learned in the last one year is the people who are most successful in early shared startups are the ones who really believe in the mission. So as a developer, the most important thing we look for is, are you really excited about building developer tools? We are not one of those sexy crypto companies. We are building developer tools for the world and actually solving problems for developers worldwide. So we look for people who really are passionate about it. And many times we see them in their background that they've worked in developer tools internally in other companies. So that kind of also helps us as using it as a [inaudible] Brendan: Well, Ankit, thanks for joining us. This was a great conversation, really enjoyed hearing about the startup world right now and what you guys are working on. And I'm excited to check out Aviator a little bit more. Is there anything else you want to add or do you want to point our listeners? Where can they find you guys online? Ankit Jain: Yeah, absolutely. Thank you so much, Brandon, for having me, this was a blast. I really enjoyed it and you're an amazing host. So thank you so much. And yeah [inaudible] Brendan: Don't cut that part out. Ankit Jain: For the folks who are listening in, please go check out Aviator. C-O. Aviator.co. Our website, it is self-serve, you can sign up and play around with it. If you have any feedback, you can always email me at ankit@aviator.co. And I'm happy to jump on a call, help you whatever way I can. So thank you so much. Really appreciate you... Appreciate you having me here. Brendan: All right. Thank you. And we'll see you online. Ankit Jain: All right. Have a good day. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts.