Ankit Dudhwewala is the Co-Founder of Appitsimple Infotek, CallHippo & SofttwareSuggest, and is an experienced entrepreneur, marketing leader, sales expert & head of growth. Most notably, Ankit has bootstrapped several SaaS companies in his career. In this article, he goes over how he can bootstrap a SaaS (CallHippo) from concept to $3mm ARR and profitable, in less than a 2 year time period.
I think people can build product. I think there are a lot of products out there have been there but the founders have not been able to reach the right audiences out there. I think marketing is the most important thing. The founder should focus on marketing when trying to bootstrap a SaaS, so that they will focus on selling and getting the first customers and then getting 10 customers and then getting the first 100 customers.
Engineering can be managed I’m not saying engineering is easy, but engineering can be managed. As a SaaS founder, if I have to do it again, I will focus 70 to 80% of my efforts on getting my first dollar of revenue, then getting my initial customers and getting my 100 customers. I don’t know why, maybe because I am in India, we have operations out of India, I think getting engineering resources is easier than getting marketing and sales resources.
If you have to control your cost, you can get a good engineering resource at a lower cost than getting a marketing and sales resource who can actually turn things and who can actually sell and who can actually generate good leads. But I think as a SaaS founder, you should spend your time there, it is a better return on your time.
We are very focused on HR. Whenever I have a discussion, it is more a question about: Are we connecting with that person? We have a very clear policy that we don’t work with anyone if I don’t want to work with that person for 20 years down the line.
So every time we add a person to the team, all my team members are even asked and I am supposed to answer the question: do you want to work with this person 20 years down the line? If there is a check there, we hire that person. If there is no check there: if I don’t want to work with that person, 20 years down the line, we don’t hire the person. This particular question has been our philosophy from the very first day. I think because of that, we have team members who have been working with us for six years, six and half years.
The engineering leader has been with us for about three and a half years now. In the last three years, the salaries have grown by about 10-12 times from when he joined us. But we always make sure, and we try to answer one single question “Do we want to work with this person 20 years down the line?”
We do have a very structured hiring process. There is a technical round, which happens with the HR team, and only when the technical round is cleared by our recruiting talent team, it comes to us. So it is not just my decision, I get all my team members on the interview round or in the interview call, and then we have a very casual discussion with the person.
This is something which we learned very recently, that we have very low user churn at SofttwareSuggest. We have software companies who have been working with us for the last six – six and a half years. Once they start, we hardly have customers who actually drop or stop advertising or stop working with us.
We started facing this issue of churn with CallHippo. For the first two years, we were growing very fast, so we never even thought of churn. It was only in the last six months that we started thinking about churn. We realized that churn is a major concern for most B2B SaaS companies, and it needs to be controlled.
So what we did was, we went back to the blackboard, and we started understanding what our ICP is, we started figuring out who are the customers, who were sticking to us, what were the type of customers, what were the industries were sticking to us for a longer period, which type of customers were giving us higher NPS scores and we figured that out and then we started building ONLY for that segment of customers.
In the initial days, we were going all out, we were telling anyone who would come to us and we will say that we are building for you and there is no “no’s” for no lead in the world. I used to listen to interviews, and I used to listen to other founders who were very successful, and they will say that we are very focused their efforts and marketing for only this one type of organization. I would think: how were they doing like $100-$200 million in revenue?
But I was very stupid to think that those guys were not very smart and I was the smartest one who was building for everyone. I knew I was not saying no to any customer, but eventually when churn started hitting us and we realized that churn is a serious problem for SaaS companies, then I could actually understand and decode what they tried to say.
Six months back after we did this entire process and now things are starting to look much better for us and our churn numbers are going down. We are now almost hitting negative churn. We are almost reaching that point where we are starting to say no to a lot of customers. In fact, sometimes it happens that we tell no to a customer and they go and give us bad feedback on platforms and they even go to our Facebook page and give us bad reviews.
But we are very clear about that, that we don’t want people who don’t fit our ICP. I think that’s the way to do it. I mean, if I have to do it again, I will go back and I will just build for one ICP. Even at zero revenue, I will try to figure out what my ICP is and I will try to build for that ICP.
We have a couple of features, which focused on these particular ICP’s and when you compare it with my competitors, you will not find this feature in my competitor. Because my customers don’t find that feature in my competitors so they don’t tend to churn out. That’s what we try to control our churn organization.
You should do an experiment with three or four products, otherwise you’re actually selling to everyone. I had my conversion rate from signup to sales at about 35% then. I was actually selling to everyone, now we have controlled it and it has gone down to 15%. We are telling them “no”. So you shouldn’t sell to everyone I mean, three or four use cases is good. You experiment with real use cases, then come down to use case then probably come down to one use case that often happens over a period of time.
At the very outset, telling that I want to do only this particular use case and I don’t want to touch any other use case will also not be smart. Going all out and telling everyone that I’m building for everyone is also not very smart.
As an organization, we have never focused on building a perfect product and I don’t think the perfect product exists. We have been a very MVP focused product. What we’ll do is we’ll understand the timeline which we have, we’ll fix a timeline that we need this product out, say in three months time, and then we will work backwards. We’ll first make a complete feature sets and we’ll think what is the best-case scenario.
We write that down and then we say that, yes, if you build this best-case scenario it will take nine months or 1 years time. Then we start removing things which we are not needed in the best case scenario so we try to shorten the time. Then we do this step a couple of times. Ultimately what I tell my team is that what we do is an “MVP of MVP’s”. So we go out with a really light product, then we do experiments with our features so we are out in like five days time and we will build that feature and we will put out it in the market.
We’ll also do things like put buttons on the product, and then we let the users perform an action there like “click that” and then we tell the user that this feature is not available and if you want this feature and if you think this feature is valuable, then talk to our product manager. We’ll do all the experiments and we try to avoid engineering. If someone comes with an idea, we will still use Google Forms. We will tell the team member that let’s experiment this idea with a Google Form. I will tell them to call customers up and see if they really want it.
We avoid engineering as much as possible even if the customer wants it as we are going for an MVP event to see if the customer is really using it, and if they’re using it, we keep building on this and adding one particular facet to it every release and build things over time. I’m a complete believer in MVP. I think building a complete product when you bootstrap a SaaS is not very smart and unless and until you have lots of funds in your bank and you’re doing something which is very innovative and your objective is to experiment and do that big experiment and see if it can be successful.