Build needs, not wants
I won't use your product out of pity or to support you.
I get it, you know how to code and engineer a solution. In fact, when you see certain SaaS products you be like “I can easily do this too” 😏
Understand: It is not enough to have an excellent idea, you’d also need to build what people want or need(I will always go for need, more on this later!).
As we have established in a previous issue, indie hackers build for profit and it’s a whole new ball game when it comes to creating what folks will find valuable enough for them to pull out their credit card and subscribe for a monthly or yearly usage of your SaaS.
You see, when you are writing code as an employee in a company, you get paid whether the code contributes to the bottom line of making money or not. However in indie hacking, you write code with making money in mind from day one.
Why will I pay for your stuff?
There are a couple of factors that will make folks pay for your stuff.
Do they find what you’ve built valuable?
Even if they do, can they afford to pay for it?
How long will they be able to continue paying for it?
Think about it, how many times have you paid for a subscription to a service and canceled it later down the line when you are strapped for cash or you have other priority expenses?(don’t worry I do it too!)
When my needs coincides with what you provide as an indie hacker, that’s when you have me as a customer.
I often see folks who just started indie hacking sort of plead for usage of their products. To me that’s quite interesting as I don’t think I’ve ever used any product out of pity for the creator.
No, I won’t use your product just to support you. I will use your product because to solve a problem for me and I can afford them.
I know I have written before about scratching your own itch but there is a fine line between building something that solves just your problem and building something that solves your problem and is also valuable to others that they’d pay for it too.
Taylor Otwell and Forge
You all know I’ll always cite real world indie hackers and one of my favourite has always been Taylor Otwell, the creator of Laravel. Let’s take a look at how he built what folks needed and not want with Forge.
After Taylor Otwell had phenomenal success with Laravel, he noticed that for him, deploying a Laravel application was sort of a pain because he had to do a lot of stuff on managing and configuring web servers manually.
Being entrepreneurial, he thought to build a web app to make deploying Laravel applications easy and that’s how Forge was born.
Taylor launched Forge with little expectations for usage. In fact, he predicted he will make $500/month from Forge but little did he know how wrong he was because he built a solution to a need.
Folks building with Laravel needed to easily deploy their applications and manage servers and what better way to do that than to use the same tool the creator of Laravel uses to deploy and manage servers himself.
Forge went on to replace Taylor’s salary and then some.
Adam Wathan and Tailwind UI
Adam is another one of my favourite indie hackers. He made a beautiful utility-first CSS framework called Tailwind CSS which blew up and got world-wide adoption(I should know because I use it myself)
Even though Tailwind CSS gave folks the building blocks to build amazing UI without the hassle of maintaining a CSS file, some users of Tailwind needed pre-made components and website templates based on Tailwind CSS that they could just copy-paste and speed up building their projects.
Turns out this was a brilliant idea and they were quite a number of folks who needed this. Tailwind UI has made over $1,000,000 in its life time so far.
Wants change, needs hardly do
I can go on and on but I think you get the idea from those two examples. It’s good to build what people want but what’s great is building what they need.
Building wants can get people excited, heck you’d get the likes and shares but in the long run folks will only pay for what they need.
So as an indie hacker that should be your focus; building what your users won’t see as a want but a need to solve the problems they care about.
To put another way, chose to build must-have instead of nice-to-have.
Understand: if I want your product today and not need it, I can as well don’t want it tomorrow but it’s hard to change needs.