I would like to show you a SaaS project I have created. It has taken me about 7-8 months of work to arrive to the point I am ready to show it to people and get some feedback so please be respectful.
It is an uptime and performance monitoring platform which currently has a web app and an iOS app. Right now it supports email, push notification and Slack alerts as well as team management. I am planning to add more features and support more platforms in the future.
I have developed it as a microservices architecture using Go. Services are deployed as Docker containers on CoreOS boxes and I use etcd for remote config management.
It's running on AWS and I have spent a lot of time making the deployment process very solid, using Terraform and Ansible.
Web services are written in Golang, I use Postgres database to store the data, the web app is written in Django and the mobile app uses Objective C.
I'd suggest exposing more technical information, e.g. documents and guides, on the landing page. It's hard to evaluate the value of a free sign-up from just a few lines of large font text and pictures of iPhones.
In the end, the technical solution is what you're selling. The iPhone app is a nice to have, but is mostly orthogonal to the important problem.
The architecture sounds nicely choosen and well executed (according to your comment) but i miss some additional information on your website.
Especially about how you plan to be always online. I see the same issue as with statuspages. Their value is actually more their stable platform than the code they produced, the most important feature the uptime.
It's a good question. Right now I have microservices running on AWS, in 3 availability zones so it should be resilient to an issue in single or even two zones.
Services are also deployed in autoscaling groups so if one of the servers goes down, it will be replaced with a healthy instance.
Right now everything is running in us-west-2 region but in the future, if it goes well, I'd like to spread servers across more regions in case there is some big AWS issue in one region.
Microservices also cache remote config so if etcd cluster goes down they continue working.
Plus I have a very high test coverage so the code should be robust enough.
Another potential issue could be scaling of the database. As I only use one RDS instance now.
In case I would have lots of users using my service, which would be a nice thing, I would consider moving from RDS to my own Postgres database (which could be scaled more than RDS) plus moving metrics data to something like InfluxDB.
Well done. If you are happy to expand further on how you managed to set aside the 7-8 months of time on this I'd be interested to hear. For example did you do consulting on the side or something?
I want to do the same thing but I don't really like consulting and I'm afraid of burning up all my savings.
Hi. Yes I did some consulting work and also moved to a cheaper country temporarily.
Of course, I sacrificed a lot of potential income as I was mainly doing remote contract work and compared to London rates I could get it was a bit lower.
But it paid my bills and allowed me to do this while keeping most of my savings intact.
My main frustration with Pingdom was their poor mobile app. So I am trying to focus on having a really good iOS app to start with as I think mobile is a big part of value of a platform like this.
Later I will also be adding some unique features I think Pingdom doesn't have. Also I can provide the same service as Pingdom but cheaper.
[+] [-] richardknop|9 years ago|reply
I would like to show you a SaaS project I have created. It has taken me about 7-8 months of work to arrive to the point I am ready to show it to people and get some feedback so please be respectful.
It is an uptime and performance monitoring platform which currently has a web app and an iOS app. Right now it supports email, push notification and Slack alerts as well as team management. I am planning to add more features and support more platforms in the future.
I have developed it as a microservices architecture using Go. Services are deployed as Docker containers on CoreOS boxes and I use etcd for remote config management.
It's running on AWS and I have spent a lot of time making the deployment process very solid, using Terraform and Ansible.
Web services are written in Golang, I use Postgres database to store the data, the web app is written in Django and the mobile app uses Objective C.
I used Oauth2 for API authorization and also open sourced my Go implementation of the spec: https://github.com/RichardKnop/go-oauth2-server
I am looking forward to feedback. Also ask me any questions about the tech if you want :)
[+] [-] jonaf|9 years ago|reply
[+] [-] brudgers|9 years ago|reply
In the end, the technical solution is what you're selling. The iPhone app is a nice to have, but is mostly orthogonal to the important problem.
Good luck.
[+] [-] richardknop|9 years ago|reply
I have been focusing on making API and infrastructure robust as well as having a really good iOS app to go with the platform.
Next I will need to focus on the website a bit more to make it look better as well as the admin dashboard. And after that, Android app.
[+] [-] herbst|9 years ago|reply
Especially about how you plan to be always online. I see the same issue as with statuspages. Their value is actually more their stable platform than the code they produced, the most important feature the uptime.
[+] [-] richardknop|9 years ago|reply
Services are also deployed in autoscaling groups so if one of the servers goes down, it will be replaced with a healthy instance.
Right now everything is running in us-west-2 region but in the future, if it goes well, I'd like to spread servers across more regions in case there is some big AWS issue in one region.
Microservices also cache remote config so if etcd cluster goes down they continue working.
Plus I have a very high test coverage so the code should be robust enough.
I will think of more things to do in the future.
Good idea to add more information to the website.
Thank you for the feedback.
[+] [-] richardknop|9 years ago|reply
In case I would have lots of users using my service, which would be a nice thing, I would consider moving from RDS to my own Postgres database (which could be scaled more than RDS) plus moving metrics data to something like InfluxDB.
[+] [-] borplk|9 years ago|reply
I want to do the same thing but I don't really like consulting and I'm afraid of burning up all my savings.
[+] [-] richardknop|9 years ago|reply
Of course, I sacrificed a lot of potential income as I was mainly doing remote contract work and compared to London rates I could get it was a bit lower.
But it paid my bills and allowed me to do this while keeping most of my savings intact.
[+] [-] kevinsimper|9 years ago|reply
[+] [-] richardknop|9 years ago|reply
Later I will also be adding some unique features I think Pingdom doesn't have. Also I can provide the same service as Pingdom but cheaper.
[+] [-] erroneousboat|9 years ago|reply
[+] [-] richardknop|9 years ago|reply