I’ve been thinking about creating a product of my own for a while now. During that time I’ve come to the understanding that the actual product, as a revenue making business, is less important to me. What I want to achieve is the experience to design, build and code a SaaS product from scratch.
During my short search around the web, I’ve found a lot of guides that cover the business aspects of SaaS products. I’ve yet to find a complete, free, understandable guide for a hands-on developer. Be that the case, I came to the conclusion that I will build the guide I’ve been looking for.
So this is my first blog post in a who-knows-how-long series on how to design, build and code a SaaS product from scratch – and you are welcome to join me down the rabbit hole.
General Notes
- I will not get into the business details of the product. That is – market research, business plan, revenues etc. As I saw abundance of such posts around the web I choose to skip these deliberately and just cut to the chase.
- I’m not covering the actual BI of the product I’m going to build. I want to focus on engineering issues and less on my own specific pain. I want these posts to address as many people as possible and less to serve as a diary for my problems.
- Contemplating software engineering. As this is a software development blog, these posts are not going to be any different. I’m going to focus entirely and solely on software related design, issues etc.
Write Down Your Journey
One last thing before we get to it – think about writing down what you think – just like I’m doing right now. Consider doing it in any other way: use a private document, do it in public on twitter, start a dev blog – whatever helps you. I strongly suggest writing things down. This helps with putting things in order and to organize your thoughts into actions.
This also serves as a fuel to keep on going. People might start engaging with you if you do this publicly which could help you gather some insight if you’re going in the right direction.
Now that we got that out of the way – let’s start going!
Planning The MVP
Assuming the business research is behind you and you want to start coding – first thing is to define your MVP:
A minimum viable product (MVP) is a version of a product with just enough features to be usable by early customers who can then provide feedback for future product development.
https://en.wikipedia.org/wiki/Minimum_viable_product
But when I say minimum, I really mean the actual minimum. You need to document every other feature that is “nice to have” and set it aside for the time being.
In my mind, planning the MVP helped me with the high-level design of the product. Since when I knew what I wanted to achieve it was easier for me to get down to the how I’m going to build it.
Think of, or reach out to, a specific customer-to-be. Ask the customer (or yourself) what are the most basic features he would need. Do nothing more and nothing less. Once your MVP is done, use customers feedback to further expand your product capabilities.
High-level Design
Time to start building the high-level design of your product. High-level design explains the architecture that would be used to develop the product.
In order to build the high-level design you want to build the architecture diagram. This provides an overview of the entire system, identifying the main components that would be developed for the product and it’s interfaces.
The tool I used to build the diagram is called Whimsical. I have to say that I’ve tried numerous products prior to this but I found this product to be really slick, simple and down to the point.
If you’re reading this guide it’s safe to assume you know what a SaaS product is. I’m going to split the high-level design of such a system into two main components – and drill down as we move forward.
The Management Plane
The first part which serves as the backbone of a SaaS system is responsible for welcoming customers and managing the system state as a whole. A customer wanting to use your product needs to access your website, register and start interacting with your product. The component which is responsible for all of these and more is called the management plane.
As you can imagine, the management plane is going to require a database to hold data and keep its state (users registration, website data etc.). With this in mind the high-level design of the management plane is rather simple:
Workers
After a customer successfully registered to your product via the management plane – he should now be able to get down to business. In my design I expect the management plane to create a dedicated component per customer registered to my product.
The components which are responsible for the actual work are what I (originally) call workers.
Workers are the second main component of the product – they handle the actual logic for which this product was thought of in the first place.
For every customer registered to your service, the management plane should start a dedicated worker. Workers hold a state and data which requires a separate database per worker as well.
With workers in mind, putting the picture together:
This concludes the first part of the design – don’t worry if everything is not clear at this point. I promise you things will get much clearer as we move forward.
Now that you have the general idea of what are the components of a SaaS product, the next thing to do is bringing each component to life. For this purpose you need to choose the technology every component is going to be built by.
This procedure is called choosing the tech stack which is going to be covered in my next blog post!
To Be Continued…
For now you can follow me on twitter for updates, comment and like. If you need to you feel free to contact me.
See you on the next one!