Quite often developers and agencies get tired of client work and start creating their own products: internal tools, packages, maybe even SaaS solutions. That’s the road I’ve taken myself, started QuickAdminPanel almost a year ago. Now, with first loyal customers, revenue and lessons learned, I can give you some tips on how this road looks.
1. Forget coding, your goal is to earn money
While delivering dev-work to clients, the goal is to launch successfully working IT project, and the business side is usually taken care of by the client.
When creating your product – it’s not the case. Even if your product idea is based on coding, as in our case, don’t think that your goal is to code the perfect product. I’ve recently read an awesome quote in the article The Epic Guide to Bootstrapping a SaaS Startup from Scratch — By Yourself:
Code is the least important thing about a SaaS business.
Your potential customers don’t care about the quality of your code or architecture. All they care about is whether your product can solve their problem.
And all you should care about is how to make money. And I’m not talking about millions, the first milestone is to finance the next batch of functions for your product. Basically, to survive and to not run out of money.
In other words, getting customers to buy is much more important than how polished the product itself is. Basically, you need to transform from a coder to a salesman. Overnight.
In case of our QuickAdminPanel, when first potential customers came to generate their adminpanels, no one cared how the generator is structured internally, all they wanted was the final generated code to be working. Of course, first version had a lot of bugs and didn’t generate a lot, but those who believed in the vision, stayed with us and became first customers, and now more and more people join in. But not because of our coding abilities – mostly because of my ability to sell the product.
2. You will have no idea what you’re doing at first
When we started building QuickAdminPanel, it was mostly for our own purposes – to generate the code for data-management projects that we work with.
And we thought to replicate similar functionality to the world. Boy, we underestimated various use-cases for adminpanels… Just compare the first video teaser of QuickAdmin in June 2016 and the latest demo from December 2016:
Yes, we’ve made a few pivots in code generation process, function priorities, even pricing – and then basically prayed that someone would stick around. But, to be honest, we had no guarantee at all – we’re basically building out our product, having no idea whether someone would actually buy. I’m glad they did.
I’ve seen that happened a lot for IT products when the founders have awesome idea, and then that idea is given a “reality check”, where it appears that customers needed it from a different angle, or even in a totally different way.
As famous boxer Mike Tyson once said,
Everyone has a plan ’till they get punched in the mouth.
So you get punched by reality, and then you can choose to change your vision a little, or close the product.
3. If you build it, they won’t just come
Marketing and sales. If you don’t have any experience and desire to dive into these disciplines – please, please, don’t start your product at all.
If you build your product and put it out somewhere like GitHub, no one will care (unless you’re someone like Taylor Otwell). And a few lonely tweets from your account won’t help much.
There’s a theory that people are ready to buy only on the 7th-8th interaction with your brand. First they hear about you from a friend, then read a tweet, then follow your work for a while, try your product, then forget about it, and then MAYBE will return with money at the time they actually need it.
Something like that happened with QuickAdmin. At first we’ve got quite a lot of traffic (thanks to this popular blog and a few influencers on Twitter), but no one bought the licence. But we didn’t give up – we knew the product wasn’t too strong at that point. So we’ve built more functions, mentioned QuickAdmin in newsletters, blog articles, tweets, emails to important Laravel people etc. And at some point something clicked.
There was a sale. And another one. And some people started thanking us for an awesome tool. Then we knew we’re onto something here. But yes, usually the purchase came from people who followed us for a while.
4. Unplanned time: support, maintenance, bugfixes
Of course, we all know how it happens – if you estimate time for something, reality will double/triple it for you. It’s especially true when creating your product and new ideas come up all the time. So roadmap is constantly changing, for whatever reason.
And not only that – while planning to build a feature X in two weeks, you don’t plan the time you would need for answering support requests, fixing bugs, doing some maintenance work or writing help articles.
There’s huge amount of unplanned time that doesn’t go directly into building the product.
So my advice is don’t over-promise to your customers, try to mention as little dates as possible, and better over-deliver if you can. Otherwise, if they expect certain feature on a certain date, and they don’t have it – you will be treated as a liar.
5. Wanted to run away from clients? Now you have many more.
One of the most common reason for developers to create their products is that they are tired of “dumb clients” to tell them what to do. Of course, we are developers, and we’ve seen how business works, so we can create awesome products without any help now.
But the problem is, when trying to run away from demanding dev-work client, you are now raising a new potential army of clients. And believe me, they are demanding too. Actually, it’s easier to tell the dev-work client to hold off that stupid feature request than tell something similar to a potential product buyer, if they are voting with their money.
Similar things happen when developers go from full-time job with one boss to a freelance career, which they think have no boss. And they end up with many bosses for many projects. Not sure if it’s a win.
So if you want to build a successful product, customer success and customer support mindset should be a core thing for you. You need to genuinely care for your clients to succeed with the help of your product. Even if sometimes you need to do some extra manual work in the beginning – believe me, customers will thank you later with their wallet, and bring more friends with them.
6. Talk to people
It might sound extremely obvious, but in order to know what people want, you need to talk to them. A lot. Actually, no – the most important part is to listen to what they say.
For us one of the biggest part in QuickAdminPanel journey was live-chat customer support (powered by Tawk.to). Quite a lot of people said “Hi there” and asked questions, which led to interesting conversations about how that particular person/company would use QuickAdminPanel, and we were able to build certain features by the requests, or help to clarify certain things.
The biggest wins happened when I just asked a question like “please tell me about your problem/goal in more detail, we will see what we can do” and then just shut up. People really like to be heard, and they tell all their stories in detail. And that’s invaluable, for both sides.
So, when trying to build a product, make conversations and customer support as important piece of it, as coding and creating the product itself.
Finally. Find the balance between client work and product
My final advice is to not dive straight into that river of product business. Client dev-work is not that bad, even if you have to deal with sometimes silly client demands. They pay you money for it, after all.
The best way is to start a product on the side, as a side-project to test out the idea. If you feel that it’s taking off, you can finance the development out of client work first, and then gradually change the percentage. It might be 90% client work and 10% product at first, then 80-20, 70-30 etc.
And if it’s your very first product, I would advise you to still keep the client work even after first moderate success. If you’re not an experience product business owner, you might still bump into problems with growth later, and client work will still bring you the bacon home. On your second/third attempt with a product you might jump into a real success then.
Anything you would add to these tips? Have you started your own product – was experience similar or different?