In the last episode, I talked about how we want to niche down, in order to step foot in the crowded hosting market.
Now, I will tell you how we plan on serving this niche and what core feature set we will be using to develop our MVP (Minimum Viable Product).
From Zero to Startup - The series
We are two passionate developers from Germany on a journey to building our own profitable SaaS startup from scratch. In this series I will share everything we learn along the way, from coming up with the idea, coding a prototype, getting our first users and scaling to infinity. We are starting from absolutely nothing but our coding skills. We will not rely on any external funding. We are Lukas Mauser and Jonas Scholz and this is Zero to Startup.
Our hosting platform is targeting freelancers and web development agencies that have small and medium sized clients.
From my experience of working in that field before, I came up with these core requirements that we want to focus on:
One of the primary influence for small businesses when choosing hosting. They don't really care too much about 99.99% vs. 99.95% uptime, because they don't even know what that means and don't really track it anyways. A lot of times they are operating in one country and their clients probably would not even notice if their service was down every day between 3:00 and 5:00 AM.
But even a few Euros difference can change the decision for a hosting provider. So as a freelancer or dev agency you want to make sure to be able to offer them a fair price, while still collecting a decent margin.
Now we are stepping into a difficult territory here and I feel like I need to clarify this first. In general it's probably not the best idea to go after price shoppers. And we certainly don't want to end up having low cost as our USP finding ourselves in a race towards the bottom.
But we need to make a general distinction between companies that are able to spend unlimited budgets and others that are somewhat more restricted.
Wordpress is running everywhere. But when developing custom software the requirements are often quite complex and with lot's of providers you quickly run into limits. Not being able to run your code is a hard "no" when it comes to choosing a hosting provider.
We thought about limiting the technology, for example to only support Node projects, or PHP, or whatever... but realized that custom dev projects are very different. This level of niching down might make it very hard for us to find initial users. So the plan is to support docker. That way developers can run almost everything and we have a clear target audience to talk to.
This is directly tied to the first point: cost. AWS can be hell, if you have never worked with it before and it can take you months to fully understand just a small part of their platform. The less time you spend with deploying stuff the better. While some freelance developers or development agencies are very capable, server management is usually not their main expertise. And spending a lot of time getting efficient in it, only pays off if you are getting big. For our MVP we will prioritize fast and easy setup and really try to nail the UX. Bad UX can become frustrating very quickly and especially in the early days, we don't want to loose users, because they did not find a button.
On top of that there are basic requirements to be fulfilled, like decent uptime, security and performance. These are all important, but there are layers to it. Like mentioned before, for big enterprises 99.95% vs 99.99% might mean a difference of 100.000€ in revenue while the same change will be 0€ difference for small businesses.
The meaning of MVP is interpreted wildly differently.
I've read some very different opinions out there on what an MVP should look like. Here is what I think of it:
MVP stands for minimum viable product.
In order to be viable we have to survive and offer a solution for our target audience that is at least as good if not better than the ones our competitors have.
Often times I've heard something like: "Just throw any code out as soon as possible". And while I think this is the way to go, and user recruiting should start then already, it is not the destination of a viable product.
In order to have a viable product we have to deliver on all of the requirements listed above. I used to think that a strong USP is enough. For example cut cost by 50%. But a strong USP is useless, if you don't fulfill basic needs. It's a multidimensional problem. Half the price does not mean shit if you only get half the uptime, so it's very important to consider that.
Keeping that in mind, it's very unlikely to deliver an MVP in a few weeks. We can throw out code in few weeks, create a landingpage, but in order to fulfill all the requirements listed above in way that's as good as or better than our competitors do, it will probably take some time.
And that's good! Why? Because it creates a little moat. Other competitors will have to go through a lot of hard work and pain in order to deliver something valuable. Yes, competition is huge in the hosting business, but competitors doing a very good job at it are much more rare.
I just described, why it'll probably take months for us, to build an MVP. So the question arises, whether we should do it at this stage we're in already? So far, our niche and MVP requirements are only educated guesses so should we try to validate these first before spending months of building? More about validating our idea in the next episode.
Our hosting platform is targeting freelancers and web development agencies that have small and medium sized clients. In order to serve that niche, our MVP will be focused on a cost effective solution, that supports a wide range of technologies and prioritizes developer experience.
Building an MVP that fulfills all these needs probably takes a while to build so the question arises whether to do some form of validation before? Check out the next episode to find out how we decided.
Check out the product on https://sliplane.io.
Feel free to comment or get in touch with us to talk about any topics you are interested in or questions you have about the project in general.