Transcript of Serial Founder: I Failed For 3 Years, Sold A Company, Then Raised VC On A Napkin | Ep. 459 with Girish Redekar CEO and Co-founder of Sprinto

We hadn't written a line of code when we closed the first round. It was literally me explaining this on a napkin.

Girish Reddikar was broke when he taught himself to code in his late 20s. He bootstrapped RecruiterBox to thousands of customers, sold it, and now he's the CEO and co-founder of Sprinto.

You know, the fact is that I did try 5 or 6 things and over 3 years before that, that didn't work. We just keep building stuff which nobody wants.

What did failing for 3 years before teach you that success never could?

The simple thing it taught me is that—

Girish, as a kid, in your words, you were notoriously quiet and good at being invisible. How hard was it for you to transition from that person to being the CEO?

Oh gosh. Well, I think Of all the things, I'd rate myself as an extremely accidental founder and CEO. I never planned for this to happen, to be honest. You know, a bunch of things sort of led to the other end and landed me where I am today. In fact, right under the point that I did my previous startup, I didn't know that I was gonna do a startup. Honestly, in fact, when we started that business, we didn't know that what we were doing is called a startup. We just thought we were running a software business. We taught ourselves programming, both I and my co-founder. We didn't know how to program until then. So that we were already in our late 20s and we, you know, we wanted to do this thing and we were broke, so we couldn't hire other programmers. So we had to sort of teach ourselves to do what we needed to do. And that's how the first company started. And, you know, between the two of us, we go back a long way. We've sort of, you know, known each other for a couple of decades now. And the reason I mentioned that is every time we do a startup, we kind of decide that who's going to be the CEO.

And I typically am better at the chaos of 0 to 1, whereas my co-founder has a brain that's really wired for scaling a company like 1 to 10. So that's typically how we sort of distribute the responsibilities between us. But, you know, like I said, both being a founder as well as being a CEO was extremely accidental. I never thought that I was going to do it right until the Well,

starting to code in your late 20s, that's very late. Most people I know, even myself, I think I started at like 12 or 13 coding, although I stopped. So maybe it's a better thing to start later in life. Was it harder because at that time maybe you had more life responsibility?

I guess, uh, you know, like in the sense, like we, we were taught like a couple of coding classes in college and so I've coded a little bit, but never coded professionally right until the point that we had to. So there was this feeling and a massive imposter syndrome when we first started. We had no idea what we were doing or even if we were doing it right. But, you know, thank God for the internet and, you know, you could actually put something out there and learn slowly. So it was hard in the sense that for a long time you didn't know if what you were doing made sense at all, or if you were just completely on the wrong path. But I think over time it did get a little easier and it did, you know, when I remember this time when, you know, there was this small bit of something that we wrote and we just put it on a server somewhere, which was thousands of miles away. And it sort of shot up this website that I could actually access from my browser and there was just like this bulb that went up in my head, which is like, oh great, this actually works.

And I think I got addicted to it in a bit. Like, just the thing about you can make something and you can put it out there and other people can sort of experience it, that can get addictive pretty quickly. At least for me it did. And so yeah, that really helped. I think, again, it wasn't something that I planned on doing necessarily, but— once I tried it a few times, it just became something that I couldn't stop myself from doing.

So you bootstrapped RecruiterBox to thousands of customers and then you sold it. What does it take to build up an app like that?

Of course, I'll be pretending if I say that I know the answer to that, but the fact is that I did try 5 or 6 things and over 3 years before that didn't work. So I kind of stumbled into something that actually worked. So it's I'd be lying if I say that I have a recipe for what actually makes it work. I think the important point is eventually, if you're solving a problem that in some way or the other, I would simply— my lesson from that entire experience is that it's more important to get married to the problem than the solutions and the ideas. And I've been guilty of this more than most people, which is— just the same thing that I mentioned earlier, it's so addictive to build and you feel like you have this immense power at your fingertips and then you just keep building things. You know, it can also lead you down the wrong path where you just keep building stuff which nobody wants. And I did that more times than I can remember. But I think RecruiterBox was one of those things where it was a very simple idea. It was a CRM for hiring.

You know, as a company, you You hire a bunch of people, you need to keep track of who you've spoken with, who you haven't, what stage of interview they are at, and so on and so forth. And that's an important job. It's a boring, unsexy thing, but it needs to get done. And turns out there was a, you know, that sized hole in the world and that it felt, it fell into that gap. And so we could basically build a viable business around it. So I guess my lesson from that is, Quite simply that if you get married to a problem instead of getting married to or getting excited by just the solutions and the ideas, then good things can come out of that.

With the ability now to create anything at your fingertips, you could solve so many problems. You almost get caught up in what problems to solve, or you're going from problem to problem. So how do you now hone in on just one idea?

That's a good point, Daniel. And the way I think about this now is as building becomes cheaper, the onus on what you build is only that much more expensive. That's where scarcity lies. And one of the things that, at least my way of thinking about it is, A, you need to be a little bit more critical about whether the idea that you're solving or the problem that you're solving is large enough, it is painful enough. So, is it like a top 3 problem for somebody and who's ready to pay for it? And, you know, it's sometimes there are lots of problems in the world that you can go after solving, but if somebody's not really, really ready to, at least in B2B, it means that unless somebody's ready to shell money for it, it's not a, you know, large enough problem or deep enough problem. And that's something that we need to be increasingly mindful of. And the second one is like, even if you did land on that problem, it's not like you just white coding something on it in a few hours is going to immediately solve the problem in exactly the same way that the customer needs it solved.

Like, this does not remove the need of being extremely close to the customer and their pain points and understanding it as intimately as they would, as experiencing it as if you were in their shoes and being able to basically think about what the solution might look like. None of that goes away. It simply means you have more competition. There are more you know, more hungry people looking at that. But your ability to actually empathize with your customer, confirming whether the problem is large enough or not, does not go away. In fact, when I did my second startup, thanks to all the battle scars that we had from a previous one, I remember going through this book called The Mom Test. I'm not sure if you ever come across it, but it's basically a book. It's a small book and it's precisely designed for engineers and builders like myself who get happy ears saying that, hey, this seems like a great problem to solve. And somebody said that they have this problem. But the idea of the book is most people are polite. They're kind of like your mom. If you say something that I'm going to build this and she'll always try to encourage you and do that.

But if you actually build it and take it to them, they'll not necessarily buy it or shell money for it. So, the idea is about how do you have conversations with your prospective customers to know to make sure that you're building the right thing and it's worthwhile building. And I feel like that book changed my life. And I promised myself I'm not going to write a single line of code until I did what the book recommended in terms of what is it, what do you need to do? Like you need to have a certain number of interviews with your prospects to know that it's truly a large problem that you're solving.

What were you able to do to validate?

So when we decided to do something around Sprinto, which is, you know, a problem around helping companies. At the time, it was primarily around helping startups build trust with their enterprise clients and the safety and the security and privacy due diligences that are required. I literally, you know, set up, I think, about 30 to 50 interviews with fellow founders because the easiest thing for me to say at the time was, hey, this is a problem that I faced in my previous company. So, I'm my own customer. So, let's go build. But remember, I promised myself I'm not going to do that. So, I actually went and interviewed about 30, 40 other startups actually truly understood what the problem was. In fact, the idea itself changed a little bit from the beginning towards the end of what it was going to be. And then we knew it was something that was worthwhile building.

Do you think we're running into this era where somebody has a problem, but they don't necessarily have to go to somebody else and pay them money when they can have it built for themselves?

Yeah, I think for, you know, there's a certain class of problems where that will be true. And obviously with AI, that's going to be true. But there are problems that are deep enough where people potentially not necessarily know how to solve that problem and they need help. And there is a certain degree of leverage that is still there. So I would still say that there's an alpha in domain expertise of in the problem statement that you're going after, rather than just people having to be built. There is a class of problems that will actually go away because of that. That's not to say what you're saying is untrue, but there is a separate class of problems that will still remain, which would likely require you to be the expert who knows how to solve that problem, either because you solved it for like a bunch of other people or because you're just a domain expert as compared to the customer that you're doing it for.

Would you say too that It's obviously, it could be cheaper to create, but because of that, and I think you mentioned it before, it's almost like a democratization of creation nowadays. That means it's even more expensive to market.

Yes, I think it's more expensive to market. It's more expensive to know whether you're doing the right thing. There's just people putting all of this thing into the ether. There's just amount of noise overall in terms of what can be built is so much larger so that standing out of that is becoming that much harder. So, you know, taking a product to market is harder today than it was 5 years ago. You know, finding a problem that's large enough that people are not solving it, are not able to solve it themselves, but need something which is like an external help or an external product to be able to solve it is actually harder. So both of those things are harder.

When you're solving something for enterprise, is that different than when you're solving something for, let's say, general founders, maybe smaller businesses?

Yes, immensely different and on multiple counts. You know, when you're selling to smaller businesses or founders, you typically have one decision point in the sense that the founder is trying to make a decision of what's best for their business. And if you're able to convince them, you know, they purchase your product. That's as simple as that. Whereas enterprise sales tends to be extremely, extremely risk-averse. And that single thing defines everything about selling products to enterprise, which is, they are a lot more about downside protection. So you need to do like a bunch of things to just rise above the bare minimum of what they need for you to be in terms of just downside protection. So you need to have the right sort of what you can call like security and privacy and a bunch of other features already in place. You need to have a good answer to why not like some incumbent who's been there for 20 years and you never get fired for using that guy, regardless of how well your product works. Remember the old joke of nobody gets fired for using IBM. So, you need to have a good answer to that.

And I think what a lot of people miss is that it's not good enough for your product to be 20%, 30%, 40% better as a result of that. Like, they'll always pick an incumbent. Like, you have to actually put the bar a lot higher. So, you have to build something that's 2x, 3x better for them, for it to basically be able to put up with the risk that comes up with using like a nobody, which is what you'd likely be when you're first selling to the enterprise.

What do you think is the biggest lie that founders believe when going after enterprise clients?

I don't know if there's a lie, but I think at least I underestimated the amount of customization and rigor that is required in order to just sell to an enterprise, like both from a product as well as a sales standpoint. And I feel like that's something that all of us have to learn the first time we do this. It's just, it's a different set of muscle groups that you need to develop as a company. It's not as straightforward. There are committee decisions being made on the other side. There are multiple stakeholders, all of who have to be happy about buying your solution. One of them saying no to it can completely derail the process. So how do you sort of build and sell for that is like a completely different— muscle memory that you need to develop. So I think regardless of how prepared you think you are, you always tend to underestimate the amount of effort and work required in it.

I would imagine most people think compliance is boring paperwork, yet you saw a business there. What made you think like compliance and enterprise, this is where I'm going to go after?

I think I've always had a soft spot for boring, unsexy problems that have large They're simultaneously extremely painful, but also high value. And these are the set of problems that nobody wants to touch with a 10-foot pole, but there's something about them that I find pretty attractive. And fundamentally, if you really look at it, every business depends on other businesses to run its operations. Not every business can be good at everything that it does. It depends on other businesses. And that dependency on other businesses typically leaves a digital trail. And we are fast moving into a world where people want assurances that the digital trail is safe, secure, private, and it doesn't leak the data into the wrong hands. So, I'll give you an example, right? Like, one of the conversations that I just got off in the last few weeks was, a window dressings and curtains company. And I was very curious, why the hell do you need compliance? And they were like, hey, we are suppliers to Bed Bath& Beyond. And, you know, they pass us order information and supplier information. And that comes obviously in some digital format. And they want us to make sure that we maintain the privacy and the security of that information.

Now that makes sense, right? You see, the world is full of these things. Like, you could be selling brick and mortar and other things, but you will eventually leave a digital trail. And security and privacy of that is important. So, the way I look at this is, you know, if we are good at what we do, we actually increase the GDP of B2B commerce, and that's our goal. You know, that's how we look at this internally. This building trust and removing friction from businesses in terms of the transactions that they do is actually a worthwhile job, and it might seem boring, unsexy, but it's extremely, extremely valuable when done well.

Do you find that sometimes you go after to solve a problem such as this, But you realize the impact it has is almost a greater sale.

Yes. I'd be lying if I say that I always knew how large a problem this is and perfectly estimated the market. One of the things about this market that has always been, I've always been surprised by the size of the market. You know, as founders, we tend to be extremely optimistic about how large a problem this is. But I've always been pleasantly surprised on the other end of it where, you know, the problem has turned out to be always larger than what we thought it was or more deeper or more painful than we thought it was. And that's always, you know, I'm happy to be wrong on those counts and it's happened more than once.

Everyone says it's a trillion-dollar industry. Everyone, I love the pitch. I've heard so many pitches from people. They're like, I'm building this business. It's a $25 billion industry. But I don't know anyone that ever has paid for that. It's like an estimated amount of possibility, but not realistic.

Yes. And I think, you know, having done this a couple of times in startups and talking to investors and trying to make business cases for this, I think there is a— everybody recognizes that there's a certain degree of conceit and fugazi that's involved in coming up with market sizing. And But the point is that when you start thinking about it, at least when you put some number to the paper, it trains you how to think about the problem. And if it's large enough, it doesn't really matter if you got it an order of magnitude wrong. Like they say, right, all models are wrong, but some are useful. So this is that sort of a thing where all your business models are going to probably turn out to be wrong and your TAM is, but it's instructional. It's useful to do that exercise nonetheless.

What has helped you as one of the top things that you do in order to show investors why it's a good idea to invest?

I don't have a general purpose answer to that. You know, honestly, I've done 2 startups. One is bootstrapped, the other is VC funded. So this is the first time I'm doing a VC funded startup and I've done like a couple of rounds, but I can't pretend to say I understand everything about how the VC world works, but—

You went bootstrap to VC, big difference, right?

Yes.

What worked in the beginning, round 1, that you realized in order to get to round 2, maybe you had to change?

Oh, with startups, I think as you go to every subsequent round, you know, the dial really changes from promise to proof. And what I mean by that is your early rounds are really, really about, you know, how much promise do they see in you as a team, as founders and the early team. So, you know, it's about, are you capable? Because I think most VCs also understand at early stages is that it's likely that whatever you started working on will change, something will change, but you as founders will probably be the only constant that we are investing in. So I think they use the business that you're building as a conversational point, So to speak, as to, okay, let's have like an adult conversation about what you're building. But a lot of those things can actually change, including what you're building and who you're building it for and so on and so forth. So it's a lot about promise and what you think you can build, and you can just draw any sort of extrapolation curves from that. But as you graduate from pre-seed, seed, A, B, and C, like as you start going down the alphabets, it starts becoming more and more of proof, like in the sense, your track record.

Like at some point it reaches a point where you can look at this in a spreadsheet and say that, look, the business has grown this way at this gross margins, at this NDR and so on and so forth. And this is how it'll likely grow into the future. So you start looking at it more and more as like a public market would. So, you know, that transition happens somewhere in between. So I think that's one of the things that we as founders need to get trained to, in the sense, at some point it is, It becomes financial modeling rather than just promise. So, and you need to start, you're somewhere in that spectrum.

I'm curious, the furthest letter that somebody has done?

Gosh, I don't know. I think I've heard like a G. Like a G? Yes.

Can you imagine what Z is? I don't know what it would be, but Z would be insane. I've always bootstrapped. I've never raised money myself. I see obvious positives in it. And sometimes I think like, wow, I could have scaled 10x if I had taken money, but then I'm also giving something up. What did you find that you had to give up going from bootstrapping to exit now to venture capital?

I didn't honestly think of it as giving up something. The simple idea that we had when we started working on Sprinto is we wanted to build a large company fast. And that meant infusion of capital quite simply. So just one of the things that happens as you're building a bootstrap company is that, you know, we taught ourselves programming, then we hired some junior programmers and, you know, then the company was built sort of ground up. Like we taught ourselves sales and then we started hiring some AEs and then that part was built ground up. So I've done pretty much every job in building a SaaS company, like from programming to product to design, to sales, to marketing, to customer support, and everything else. And all those teams were basically built ground up. And that's incredibly, incredibly useful from a learning standpoint. But if I look back at it, I was the bottleneck to the growth of the company at every point of time. So, the company only grows as fast as I can learn. And that's not the best way to grow a large company fast. So, one of the things that we wanted to do with Sprinto was to build a large company fast.

And what that meant is, At every stage, you're going to hire people who are better than you at doing something. And, you know, that requires a fundamentally different way of building the company. So, Splunto is built a little bit more top-down. At every stage, we ask ourselves, you know, who can we get on board to sort of do this? Who can tell us what to do rather than me telling them what to do? And that's a fundamentally different way of building a company. So, that's the path we signed up for. So, VC, was downstream from that.

How much weight carried onto the first investors knowing that you had exited and bootstrapped a company before?

I think it mattered a lot in the sense that we hadn't written a line of code when we closed our first round. It was literally me explaining this on a napkin to someone, hey, this is what I'm roughly trying, planning to build, et cetera, which we eventually—

Do you still have that napkin?

No, unfortunately not.

That would be epic. Okay.

But, you know, like we eventually had to do something for their investment committee and stuff like that, but it was raised by, from someone who knew us during our journey in a previous startup. So it's not like it happened overnight in the sense, like it sounds like it happened overnight, but the fact is they had seen us grow our previous company, see it through an exit, not just know that we exited, but They actually looked at our previous journey intimately. So, you know, most of these overnight successes, as they say, are years in the making. So that's what happened with our first round.

So you built Sprinto as a new parent. How do you chase the startup?

I honestly, you know, don't think of companies as babies. I know this is a commonly said thing where founders treat their companies as babies. I actually think of it a little differently, which is I feel like I have a responsibility towards it in the sense like I'm just a guardian of something that the company needs to find its best form. The way I look at raising my own child is a little bit different in the sense like I feel like I'm actually truly a parent there where there's something that I need to like I need to protect them from something or, you know, just make sure they grow up well in the world, et cetera, et cetera. But that's somehow not my outlook to the way I look at the startup that I'm building. I've always thought of it as something that's a responsibility that I have. And while I really enjoy it, I don't feel, what's the word? I'll give you an example of what I mean. Like when we had to sell our previous company. I often get this question about, you know, how do you feel like parting with your baby? And I felt like it wasn't that hard because, you know, I knew that the company was going to be in better hands than we were running it at that point of time because we had reached the ceiling of what we could do with that company.

And it actually needed somebody else to basically take it to its next phase of journey. And that then it was a very simple logical decision. It didn't get as emotional then. So I feel like the two look very different to me.

I'm with you. If somebody wanted to buy my company, I'd be 100% fine with parting with it. Tell me about your belief in software on how you think it should act on its own and only pull in human judgment when needed. Where's the line though between automation and trusting a machine too much?

You know, one of the things that we're trying to really focus on at Sprinto is how can we build software that works while we sleep? And most of the ways that we still use AI today is you're babysitting it. You give it a task, it does something, you look back at it, you review it, you say, this was not okay, you steer it, you ask it to rework, et cetera, et cetera. But it's still you at the wheel. You're just telling AI what to do and it does it. But we feel like the real alpha comes from the fact when you could basically describe outcomes and software could run those outcomes for you behind the scenes, and you could trust it to do it in the manner that you described it, that you would like it to do. That requires 2 things. A, software needs to get married to outcomes and rather than tasks. Like, we still today think of software in terms of tasks, like do A, then do B, then do C, and do D, and so on and so forth. And that's not necessarily how that'll work. And second thing is, like, it needs to run in an extremely reliable manner.

You can't have hallucinations. You can't have it doing the wrong thing when you're sleeping. And you can't have it, especially in something like compliance and audits, it's extremely important to get things right. You can't show the wrong proofs to the auditor. Businesses depend on accuracy and veracity of the data that you show over here. So, I think that puts a higher bar on what it means to run something autonomously in our space. It has to be extremely reliable, yet it's something that has to run in the background because that's where you get the real alpha. If you're still going to babysit it and steer it all the time, then it means you're still the bottleneck. That does not necessarily mean, however, that you're getting rid of all human intervention. Like, what it means is that humans are pulled in when required rather than, you know, you always driving it all the time. So, the analogy that I have in mind is imagine you had like an overenthusiastic employee and you give them a task and the way they'll go at it, they'll just Go at it, go at it, break into walls. And if they get stuck, they come back to you and they pull you in saying that, hey, I need some direction here.

I'm stuck here. What do I do? You tell them and they are off on their merry way. They keep doing it until they hit the next place where they are stuck. We still today use AI, which is a lot more like an intern where you give it a small task, they do it, it comes back and then you say, okay, here's the next task. Oh, you didn't do it right. You're still babysitting a lot. Whereas, We need to flip from that into like an overenthusiastic domain expert employee who you can give real large problems to and they can pull you in rather than you having to babysit them. And that's our ideal for what autonomous software looks like. And it's extremely important in our space because, A, the job of maintaining governance or risk or compliance or trust is just exploding and the number of people who are required to do that is still the same. So, you get this problem of notoriously understaffed and overworked teams who do this job. And it's crucial that this gets solved in this particular manner.

What did failing for 3 years before teach you that success never could?

Gosh, I'm not much for pithy advice, but I think the simple thing it taught me is that You know, what we mentioned a little earlier, which is stop running after the next shiny glittering thing. All of these things look great in the laboratory of your head, but put things out there, like have conversations with real humans, real customers. Those are a lot more valuable than anything cool that you could build. Like, it's still fun to build something cool and you should not take that joy away from that. But, you know, you need to basically have enough respect for the market, for the people, the actual customer who you're selling to, and get their views on that. And the faster you do that and the more you do that, the better your products are going to be.

If you started with nothing again tomorrow, what would you do differently?

Even professionally, right?

Let's say you sell this company, you're back to square one, zero with a new company. tomorrow, what would you do differently with that startup?

I don't know if I'd do anything fundamentally differently than what I've done at Supinto. I honestly haven't had much time to sit back and sort of have the advantage of hindsight just yet. It usually takes some time for all of these lessons to sort of distill.

I'll ask that in 2 years from now.

Sure.

How do you see the world in 3, 4, 5 years from now?

One of the problems and exciting things about AI simultaneously is we don't know the limit of this technology today. All our hypothesis of the future is based on the way we understand the technology as of today, but that frontier is moving so fast, it's really hard for us to guess what it will be like tomorrow. So, I don't know. I'm not a pundit who can sort of predict the future. All I do know is that the life in 3 to 5 years is going to look very, very different. It's going to look practically indistinguishable from the way it is today. In what specific ways, hard to say. And I think one of the things that I'm telling myself is, you know, while a lot of things will change, there's a Jeff Bezos quote about, you know, it's also important to pay attention to what may not change. You know, there are some fundamental things which should remain the same. And it's important to sort of, identify what are some of those things that will not change, because we get so lost in thinking about what's going to change, what's going to change, what's going to change, that we don't think about some of those things.

So, for example, you still sell stuff to people. People are going to be important. You know, understanding them, having empathy with them, like, personal connections are going to be all that important. So, yes, in the world of bits and bytes and screens, they're still humans at the end of the day. And it's some of those things are not going away. Regardless of how good technology gets.

I really like that quote. We do get caught up on what we think is going to change, but there could be massive opportunities in what is not going to change because that's where people are not looking. Opportunities are always in what is going to happen versus what will remain the same. Girish Rediker, love it, man. Great talk. I had a lot of fun. I learned a lot. I'm inspired. I always love talking to someone that bootstrapped and exited, and the fact that now they've gotten investment and you're on the trajectory, and you're also in San Francisco, which is, you know, the AI capital of this planet as far as I know. But thank you so much for joining us today on Founder Story.