Show HN: Pinglist – My SaaS Project(pingli.st)
pingli.st
Show HN: Pinglist – My SaaS Project
https://pingli.st/
6 comments
I'm confused. You said you used etcd for config management, but then you said you used Ansible. So you're using Ansible exclusively for deployment?
You can read more about Ansible[0] and etcd[1] here.
Etcd - to keep the configuration in use
Ansible and Teraform to build infrastructure
Example Ansbile + Etcd [2]
[0] https://www.ansible.com/ [1] https://coreos.com/etcd/docs/latest/getting-started-with-etc... [2] https://gist.github.com/justenwalker/09698cfd6c3a6a49075b
Etcd - to keep the configuration in use
Ansible and Teraform to build infrastructure
Example Ansbile + Etcd [2]
[0] https://www.ansible.com/ [1] https://coreos.com/etcd/docs/latest/getting-started-with-etc... [2] https://gist.github.com/justenwalker/09698cfd6c3a6a49075b
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.
Good luck.
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.
Thank you. Yes, I need to work on the landing page and add more technical details there.
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.
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.
Curious regarding current users and how user feedback is driving the priority of features.
I have only deployed the platform to production recently (couple weeks ago) so there are just few users now.
Until I get more feedback from actual users / customers, I am trying to use common sense to decide which features should come first.
I guess early customers could potentially have a big influence on how I prioritise upcoming features so I will wait for feedback.
The reason why I haven't started working on Android app yet is because I have no experience with Android myself so I would have to outsource it to an expert.
So far I have been able to do almost everything myself (I outsourced designs and initial mobile app but I have since taken over the iOS side as I know a bit of Objective C).
It is getting a bit overwhelming as I need to handle infrastructure, backend, web app and iOS app at the moment just by myself. Plus I also have a full time job right now so the time is limited.
I was also thinking about teaming up with somebody to help move forward faster ;)
Until I get more feedback from actual users / customers, I am trying to use common sense to decide which features should come first.
I guess early customers could potentially have a big influence on how I prioritise upcoming features so I will wait for feedback.
The reason why I haven't started working on Android app yet is because I have no experience with Android myself so I would have to outsource it to an expert.
So far I have been able to do almost everything myself (I outsourced designs and initial mobile app but I have since taken over the iOS side as I know a bit of Objective C).
It is getting a bit overwhelming as I need to handle infrastructure, backend, web app and iOS app at the moment just by myself. Plus I also have a full time job right now so the time is limited.
I was also thinking about teaming up with somebody to help move forward faster ;)
To me, the decision to move forward faster or not should be made in the context resource constraints and availability as well as long term goals. For a venture capital backed company, the investment provides the resources to move forward faster. For a bootstrapped or self-funded company, moving forward faster may not be a sound strategy.
In an area like infrastructure monitoring, there probably aren't first mover opportunities to capture massive market share. The market is competitive and a company will probably succeed or fail based on how well their product meets the needs of a small slice of the overall market and the quality of its financial management.
In general, talking to users is often harder for people than just building something...it's work and programming is fun. For some people, even spending money tends to be more fun than talking to users.
Accounting isn't that fun, for many people, either. The cost of an Android or iPhone app isn't just development time. It also increases the support surface. Add a platform and to delight users, it has to get the latest version quickly. Web+iOS+Android is potentially 50% more support when something breaks [assuming that it is equally easy to fix on each platform and each platform is equally reliable].
Achieving roll-out is a huge accomplishment. The next important steps are less technical and more business and personal and financial.
In an area like infrastructure monitoring, there probably aren't first mover opportunities to capture massive market share. The market is competitive and a company will probably succeed or fail based on how well their product meets the needs of a small slice of the overall market and the quality of its financial management.
In general, talking to users is often harder for people than just building something...it's work and programming is fun. For some people, even spending money tends to be more fun than talking to users.
Accounting isn't that fun, for many people, either. The cost of an Android or iPhone app isn't just development time. It also increases the support surface. Add a platform and to delight users, it has to get the latest version quickly. Web+iOS+Android is potentially 50% more support when something breaks [assuming that it is equally easy to fix on each platform and each platform is equally reliable].
Achieving roll-out is a huge accomplishment. The next important steps are less technical and more business and personal and financial.
Thank you.
Yes. That is what I am a bit worried about. Adding Android app would just introduce a new codebase to maintain and support and it would overwhelm me. I already have 3 different areas to maintain (API, web and iOS app). And I am at least familiar with all of these. But Android is completely out of my comfort zone.
I have so far bootstrapped / self-funded everything so I think I can continue moving slowly as there isn't much pressure from anybody.
I should probably continue slowly improving the API, web and iOS app and try to slowly organically grow early customers.
I will worry about Android later. Perhaps I can set some sort of a milestone for myself. E.g. if I manage to get 500 customers, I will consider adding Android app.
I have been looking at competition and I think they can be disrupted. One of the reasons why I started working on this was because I was using Pingdom before (which is one of the big players) but their mobile app was very bad and didn't work half of the time so I felt this can be done much better.
Yes. That is what I am a bit worried about. Adding Android app would just introduce a new codebase to maintain and support and it would overwhelm me. I already have 3 different areas to maintain (API, web and iOS app). And I am at least familiar with all of these. But Android is completely out of my comfort zone.
I have so far bootstrapped / self-funded everything so I think I can continue moving slowly as there isn't much pressure from anybody.
I should probably continue slowly improving the API, web and iOS app and try to slowly organically grow early customers.
I will worry about Android later. Perhaps I can set some sort of a milestone for myself. E.g. if I manage to get 500 customers, I will consider adding Android app.
I have been looking at competition and I think they can be disrupted. One of the reasons why I started working on this was because I was using Pingdom before (which is one of the big players) but their mobile app was very bad and didn't work half of the time so I felt this can be done much better.
That seems well thought out. Many overnight successes are ten years in the making. Running a business is hard.
I am mostly a backend / dev ops engineer though so that's where I can develop new features and iterate relatively quickly.
Doing also front end is a bit out of my comfort zone (at least the iOS part, web is fine as I used to do a lot of Python and Django development back in the day before I switched to Golang).
Another thing I was considering was potentially using crowdfunding to raise some money and hire one or two freelancers to help move things along faster. Especially the mobile side as I feel having really good mobile apps is the key differentiator from competition.
Doing also front end is a bit out of my comfort zone (at least the iOS part, web is fine as I used to do a lot of Python and Django development back in the day before I switched to Golang).
Another thing I was considering was potentially using crowdfunding to raise some money and hire one or two freelancers to help move things along faster. Especially the mobile side as I feel having really good mobile apps is the key differentiator from competition.
My observation is that successful crowdfunding tends to require a lot of effort. Design, literature, marketing are pretty much necessary even for projects with an established community. Or to put it another way, most of the successful crowd funding projects I see have spent a lot of money on professional expertise for promotion. Even important open-source projects with many users often struggle without it.
You are right. I should not get ahead of myself. I will continue slowly bootstrapping my company for now with my own funds.
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.
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.
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.
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.
This sounds better than i even have imagined, clearly put something about that on your website. May also create a business related blog where you can add all these architectural choices in detail. Assuming other potential customers also look for transparency in this.
About the databases, i would just make sure to have a plan when it comes so far. I dont think your website will explode in populary over night are you are not _that_ unique, so you most likely will notice it early enough if you watch closely when it is time to switch :)
About the databases, i would just make sure to have a plan when it comes so far. I dont think your website will explode in populary over night are you are not _that_ unique, so you most likely will notice it early enough if you watch closely when it is time to switch :)
Thank you :)
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.
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.
Have you considered Aurora ?
Not yet. I have heard a bit about it. What are the main advantages over Postgres?
I am not sure but I figured it would be the easiest to deploy from a scaling perspective.
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.
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.
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.
You should tell How this is different or Why is this better than Pingdom? :)
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.
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.
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 :)