OnlineOrNot Diaries 15

Long time no diary! Between late July to early September, I took the longest break from regularly working on OnlineOrNot since starting the project in February 2021.

In that time I visited:

• Paris
• Florence
• Rome
• Biarritz
• San Sebastian
• Toulon

I came back pretty eager to get back to regularly shipping features and marketing projects for OnlineOrNot, so here we are.

While I was away I read Yvon Chouinard's Let My People Go Surfing, and it reminded me of why I started building OnlineOrNot in the first place: to build higher quality software than the established products.

In short, with OnlineOrNot, I want to build high-quality software. At a loss if I must (I have a full-time job after all), but always high-quality software.

On de-emphasising the free-tier

OnlineOrNot has a free tier. It's for personal, non-commercial projects (like monitoring your personal blog), but I've always wondered if that drove the wrong type of folks (as in, not product teams building software) into trying OnlineOrNot.

So while I was away, I ran an (ultimately flawed) experiment to remove all mentions of OnlineOrNot's free tier from the marketing website (without actually removing it from the app), to see what would happen. My expectation was that sign-ups would take a small hit, while increasing the overall paid conversion rate.

I'm not going to sugar-coat it, sign-ups halved.

It being the month of August during my experiment (Europe/North America on holidays), me being away (spending zero time on marketing) likely influenced sign-ups more than removing the free tier.

I still need to wait a couple of weeks to see the impact on overall paid conversion rate, so I'll likely try running the experiment again once I've settled into a regular coding week/marketing week schedule again.

On actually "finishing" MVPs

I've mentioned it a few times in previous diaries: OnlineOrNot is built in two-hour increments, before I start work every morning. To avoid never releasing, my release cycle is quite different to regular software companies - instead of a "big bang" release once a feature is ready, or an agile/sprint fortnightly release, I try to release every single morning.

This works pretty well in practice for marketing, fixing bugs, and smaller features, but for large features (like introducing heartbeat monitoring), I found myself releasing far too early, before the feature was ready for customers: a bit too "minimal", and not enough "viable" product.

The fix is simple of course: the Early Access Program. My mistake was promoting the heartbeats feature from Early Access to public beta too quickly, and ending up with customers using low quality software.

As a result, I've spent my first week back rapidly iterating on Heartbeat Monitoring to make sure it's actually viable as a product. I've made the following changes:

• I've fixed a few bugs preventing heartbeat checks from alerting properly
• I've integrated heartbeat checks into status pages, so customers can track their cron jobs on a status page
• The heartbeat check graph now correctly shows incidents, not just successful runs
• I've moved heartbeat checks into their own infrastructure
  • I didn't know if anyone would use it, so I built it inside OnlineOrNot's existing uptime check system. While convenient, it made the code far more complicated than necessary (split across several microservices).
  • With this change, the heartbeat check system can be monitored and deployed independently, it can fit inside a single serverless function AND it can accurately monitor OnlineOrNot's uptime check system

Next up, I'll be adding email, SMS, webhook, and on-call integrations to heartbeats, so that they match OnlineOrNot's regular uptime check alerts.

Back into content marketing

Even though I know in the short-term that content marketing doesn't really work for attracting customers, I like writing too much to give it up. For coming up with content ideas, I tend to watch forums (like hacker news) to see what folks are complaining about, and write articles that fix their issues.

So now that I'm back, I'll be writing more of my classic "fixing a problem"-style articles.