Every programmer wants to build a $1M SaaS.
But most never get past $0.
Without the right approach, they waste their time, money and energy.
I made similar mistakes when I got started with my first SaaS. Here, I have shared some tips to get started with your SaaS.
1. Don’t start with a product idea
I started my first business with a product idea.
It was nothing new.
Most programmers start their business with the product idea only.
We get excited about an idea and spend most of our time thinking about it.
We make up assumptions regarding how our product would make $1M in just 6 months.
We share our idea with friends, and they praise it, not because it’s great but because they don’t want to hurt us with the truth.
Most of us start building our product just because our friends liked it.
But is it the right way to start a business?
A critical thing we miss
Most of the time, when we start building the product, we do not know whether people need our product.
Another critical thing we miss is how we are going to find our customers.
I made this mistake in the first business I started.
I wasted time fantasing about how my idea would change the world.
I never asked these four critical questions before even starting the business.
What kind of problem does my audience need help with?
What is the true pain point of the audience?
What is the solution to their problem?
What kind of product can I build to fix the issue?
Sometimes, building an app or website isn’t even the best way to solve their problem.
Your audience may need some kind of service instead of a SaaS.
What should we do?
I wish someone had told me this when I started my first business.
When you see people only talking about SaaS, you forget the fact that not all problems can be solved with SaaS.
You should first think about the above questions before considering building a SaaS business.
I built my product around an unvalidated need for people who were never going to pay for it.
2. Don’t believe limiting scope is enough
I invested around 4+ months to build my first product.
Since I was building an Amazon alternative, I assumed everyone would be my customer. So, I wanted to give them as polished an app as possible.
I was directly competing with Amazon in terms of App quality.
I believed that if I invested more time in building the app, I would have to do much less work in the future.
That’s why I tried to build an App like that.
The false belief
Most of us programmers think like this.
If, by the time we start coding, we have done everything properly — like talking to the right users and conducting interviews correctly
At this point, we think we know who we are building the product for. We assume we have a clear idea of our target customers, which makes us feel like we have properly defined the product scope.
We assume that limiting the product scope means we must release a fully finished version. Defining the scope gives us a false sense of clarity, leading us to take things lightly.
As a result, they end up investing 9–12 months building the product.
I also made this mistake. I assumed that all Amazon customers would also become my customers.
As a result, I invested around 4+ months building a mini-Amazon.
At that time, I believed that since I knew my customer, I had to invest as much time as possible in making the app polished. Once I can build the product, I will need to do very little work afterwards.
But this is rarely true.
How scope changes
Suppose you decided to build a SaaS platform that continuously monitors the price of the product across multiple online e-commerce platforms in real time.
After talking to users, you’ve decided that your product will track historical pricing data and current trends to identify fluctuations and patterns.
Your customer could set personalised alerts for specific products. You have set the scope of the product. You worked hard to build the product.
Now you have released the product. You thought you were done with the product and only had to make minor changes in the future.
After a few days, a few of your paid customers made a new feature suggestion. For this feature to go live, you have to delete a previous feature.
What happens at that point? You have to do it, as it has been requested multiple times. If you don’t do it, you’re at risk of losing a paid customer.
Now, even though you’ve defined the scope of the product, you still have to make changes.
Maybe you have to invest the next month to add the feature and make code changes just after release.
This is why you can never say, ‘I have fixed the scope of the product; I don’t have to make big changes to the codebase.’
Limiting scope can help at the beginning, but it doesn’t mean you’re done with the product.
3. Don’t spend your time like this
This is one of the curses of being a programmer.
You keep on learning and learning.
We programmers think we have to make the best landing page, so let’s first learn how to make a beautiful landing page.
We will spend 100s of hours just learning it.
Even after investing that much time, we still won’t feel confident in our ability to create a landing page. It’s because we’re in constant comparison mode.
We will compare our landing page to a successful SaaS that has hired the best designers to do this.
This will make us unhappy.
Best design a programmer needs
Once we know how to make a landing page, we will move to learning how to design.
And invest another 100+ hours doing it.
I can say this because I have done this. I was always the kind of person who would go deep into any skill I thought I might need in the future.
If I ever needed to hire someone, I would spend time reading books on how to do it perfectly in the initial stages only.
It is not just my situation; many programmers are like my past version.
If you are someone who is reading this, I want to say just focus on the 20% features which will make a difference and release the product.
Marc Benioff example
When Marc Benioff was about to start Salesforce, he focused on taking action instead of just thinking about his idea.
He first talked to a friend who ran a public company called Siebel Systems.
He told him about his idea of sales force automation.
He explained that he would sell cloud-based CRM software on a monthly subscription model. At that time, the subscription model was a new thing.
But his friend failed to see the bigger picture. As a result, Marc started his own company.
He started talking to engineers and hiring people for his startup. Then, with the help of a few beta testers, he launched his product in just a few months.
He was continuously moving forward and taking some actions to make his idea a reality.
He focused on the 20% of efforts that drove 80% of results and prioritised launching the product quickly.
This is how you need to work if you have a validated idea.