Two months in: How the SaaS that was built in 7 days is going

In case you don't remember, or missed my first article: OnlineOrNot started as a SaaS I built and shipped a v0.0.1 of in 7 days.

It was an Absolute Minimal Viable Product. You couldn't even login with a password. Still can't, actually.

You're probably wondering what it does.

OnlineOrNot is a website monitoring service that provides both uptime, and page speed checks. Last time I looked, it was the 191st alternative to Pingdom's uptime monitoring service (and that doesn't bother me - more on that later).

As I write this, with two and a bit months of operation, I have 4 paying customers out of 142 users, for a total of $66 MRR. I have since revised my pricing, now that I'm a bit more aware of the costs of keeping OnlineOrNot online.

Table of Contents

• What I started with two months ago
• What I've built since then
• What's coming up next
• Why I'm not worried about building the 191st website monitoring service

What I started with two months ago

As a v0.0.1, OnlineOrNot could only check webpages for uptime every 5 minutes, and send alerts via Emails.

Login was either via passwordless magic link sent via Email, or Google OAuth.

You could also pay for it with Stripe, with three tiers of monthly and annual plans available.

What I've built since then

Since then, I've:

• Made uptime checks run every minute for paid customers
• Made it possible to search for text in an uptime check
• Interviewed potential users, users, and friends to understand what people currently use, and what they wish their website monitoring tools could do
• Made it possible to edit/delete uptime checks
• Made it possible to sign up for a Slack integration
• Made it possible to alert Slack that an uptime check is failing
• Added retries, made it possible to wait for a check to fail several times before sending an alert for flaky checks
• Made it possible to invite an unlimited number of users to your team
• Added a chat window, for quicker customer support
• Built a weekly insights email, sending users a summary of the week's uptime checks every Monday morning
• Got added to the Slack app directory
• Sold my first team plan
• Added Page Speed Monitoring

Around this point, OnlineOrNot hit 100 users. While you'd normally stop to celebrate such milestones, I started noticing scaling issues with the service. Particularly with the database - with this many users, there were too many uptime checks trying to write their results to the database at one time.

Users of the web app were starting to experience timeouts and errors. I hadn't actually built proper error screens yet, so they looked like this:

Not a great look.

To mitigate this, I scaled up the database to buy myself some time, and got to work refactoring some code. I ended up increasing the number of checks OnlineOrNot could run simultaneously by more than 10x. I later brought the database back down to its original size, from how idle it was running.

I also went back and made the error screens useful:

Then I went back into building mode, and I:

• Made it possible to enter your phone number as a user setting
• Made it possible to invite a "Bot" user, that gets all notifications via Email
• Reached one million uptime checks. In that time, we detected 277 incidents, cross-verified at 10 data centres across the world. Since starting, 26% of pages monitored had at least one incident.
• Made it possible to control who should be alerted for each uptime check
• Enabled SMS for all paid users - unlimited for teams and businesses
• Realised AWS Fargate costs about 10 times more than I expected, resulting in me having to wind back inclusions for page speed monitoring (I used to offer unlimited page speed monitoring for teams)

What's coming up next

I'm currently adding webhooks to the service, so users will be able to forward OnlineOrNot alerts to any system they'd like.

Once that's complete, I want to make it possible to setup checks without needing to use the web app: starting with a CLI, and potentially later building a terraform provider so teams can have Uptime Monitoring as Code in the same way they currently have Infrastructure as Code.

Long-term, I plan on broadening the types of checks OnlineOrNot can perform. Particularly looking at IoT devices, ports, DNS, and SSL certificates.

Why I'm not worried about building the 191st website monitoring service

I've been working with the systems underlying OnlineOrNot (AWS Lambda for microservices, Postgres for the database, React and GraphQL on the frontend) for about four years now. In that time I've seen a lot of new developers build quick uptime monitoring tools (I mean, if you saw my last post, it only took 7 days to have a decent app going from scratch), but then give up a month later when their launches on Hacker News and Product Hunt fail to net even a single upvote.

I think the difference is in people's motivation - a lot of people build independent SaaS apps to make money, then give up when they find it's difficult.

I'm playing a different, long-term game: I'm making money so that I can build an independent SaaS app.