Six months in: How the SaaS that was built in 7 days is going
Max Rozen / August 25, 2021
Previous articles in this series:
- Building a SaaS in one week: How I built OnlineOrNot
- Two months in: How the SaaS that was built in 7 days is going
A few weeks before I sat down to write this article, I reshared my two month review of OnlineOrNot around the internet.
Surprisingly, the article was quite popular:
So I thought I'd clear up some confusion for the folks who only just read my two month review: I started OnlineOrNot on February 25, 2021, shipped the first version for people to use on March 2, 2021, and here I am in August writing the six month review.
Quick numbers
So - business is going well.
OnlineOrNot is profitable in terms of operating costs (excluding the cost of my own time) and I finally understand what Baremetrics meant when they were talking about the long, slow SaaS ramp of death.
OnlineOrNot's user growth continues to trend up slowly, with a few spiky exceptions: where a blog post has gone viral, or someone popular in the dev community shares it with their followers:
It's worth noting that the vast majority of OnlineOrNot's users come from being patient, and letting them organically find me. Typically that's either via content marketing, or word of mouth (people tend to write far better, more convincing words to their friends than I ever could).
As of the end of August 2021, we have:
- 351 users
- 8 paying customers
- $276 USD MRR
When I first started commiting code for OnlineOrNot back in February, I was using my trusty old MacBook Pro 2011 13". With rebuild times taking several seconds, I grew frustrated and bought myself a new MacBook Air M1, which made the entire dev process significantly faster.
OnlineOrNot has now made enough money to pay for that purchase, which I'm incredibly grateful for. My next MRR goal is $1000 USD.
What's changed in the last few months
Quite a bit has happened since I wrote my last update:
Added webhook support, so OnlineOrNot can alert any system on the internet when URLs become unreachable.
Fastly went down, taking the largest websites on the internet with it. I wrote an article about how to improve your error messages (based on their publicly visible error message), and tens of thousands of people ended up sharing it.
Added minimally viable Puppeteer-based monitoring, so client-side rendered apps like React can be monitored. Eventually we'll let users add their own Puppeteer scripts.
My transactional email provider (Mailgun) had several outages, breaking OnlineOrNot's email-only login system, forcing me to migrate to Postmark.
Started providing reasons for why OnlineOrNot thinks URLs are down. Up to this point, OnlineOrNot only told you your page was down, but didn't tell you why (for example: timeout, keyword check failed, or generally unreachable URL).
Onboarded our largest customer so far without impacting the service.
Added search, filtering, and pagination to the uptime dashboard (functionality that only became obvious when trying to load over a thousand uptime checks at once).
We reached 1.85 million uptime checks per week. I remember having a beer to celebrate hitting one million checks for the first time, the fact that OnlineOrNot checks more than that each week now blows my mind.
Increased the number of places around the world OnlineOrNot can monitor from 10 to 18.
Started focusing my writing more towards DevOps and folks running their own product:
I got married during Sydney's lockdown, and my wife and I decided to move to France (still a work in progress).
About onboarding our first large customer
Back in June, I onboarded OnlineOrNot's largest customer (up to that point), with over 1300 URLs to monitor. It was actually great fun to do - I got to write Python again, and wrangle the user-provided data into a format OnlineOrNot could parse.
For context: as part of OnlineOrNot's Team and Business plans, I offer complimentary setup. This is particularly handy for customers that have tried 5-6 other solutions and keep being disappointed by false positive alerts, and don't want to manually enter hundreds of URLs into yet another system that might let them down.
Thankfully I had experienced and solved scaling issues with my original architecture early on (a blessing of offering a free tier), and was able to start monitoring over a thousand extra URLs with little more than a small percentage increase in my database server's CPU usage.
Where OnlineOrNot did fail was the UI. While the backend could handle the extra load with ease, trying to render over a thousand graphs at the same time would almost crash Chrome. As a quick fix for the customer, I disabled the graphs if they tried to load too many at once:
Eventually I solved the issue by implementing pagination and filtering:
While the UI not meeting the immediate needs of my customers was pretty embarassing, I prefer it over building features my users will never need.
Side note: I've already unshipped a few features that customers suggested and never used. Knowing when to listen to your customers and when to note their feature requests for later is definitely a skill I'm working on.
What's coming next
As OnlineOrNot grows, running the business feels more and more like playing an MMORPG. By which I mean, it's pretty damn fun and addicting, but I am quite limited for time between a full-time job and being in the middle of a moving half-way across the world.
That being said though, I've been maintaining a roadmap of where I see the product going, and committing to the timeframes provided.