Four years of running a SaaS in a competitive market

When I played around with the technology that would eventually become OnlineOrNot back in 2021, a quick search showed me that there were 200 listed alternatives to the tool I wanted to replace. I thought most of them sucked.

There are even more today.

Over the years, many more started and shut down a few months later (it turns out running a business in a highly competitive space doesn't make you rich overnight). Others raised VC money or were acquired by a private equity firm, and started their descent into enshittification.

I started work on OnlineOrNot because I wanted to build software that didn't have to get worse for its users in order to maximize shareholder value. In short, it's a self-funded, sustainable business that I intend to run for decades.

It's default-alive, as I keep a full time job so that I can build the business the way I want.

I've published one of these articles every year since starting, and there were things that I "learned" in the first year, that turned out to be total bullshit by the third year. So this article doesn't just look at the last 12 months, but across the entire lifetime of this business.

Table of contents:

Principles that haven't changed
Lessons

Principles that haven't changed

While I've learned a lot about running a business over the years, there are some unchanging principles:

Two hours a day, every workday.

Years before I even started OnlineOrNot, I started hacking on my own projects in the two hours I have before starting my workday. Having a consistent block of time for myself has let me publish hundreds of articles, a book, dozens of software projects, and more.

Since starting, I worked out that the amount of time per day isn't as important as putting any effort in, every day, for years.

But how do you find time before your workday?

I started waking up two hours earlier, and adjusted the rest of my day accordingly.

No other side projects.

the person who chases two rabbits catches neither

Of course, there are exceptional folks out there chasing a dozen rabbits and managing to catch some of them - I know myself well enough to realize that I'm not that person.

Building out the marketing and sales processes to take a business from $0 to $500 MRR is challenging enough. I don't see a point in repeating the hardest part of starting a business over and over again, instead of doubling down on what's already working (this is also a lesson for picking a marketing approach, more on that later).

Solve customer pain.

When a user signs up for OnlineOrNot, I have an automated email going out asking what brought them to sign up today. I explicitly tell them I read and reply to every email. This is the main source of my insight for building product.

I ask my customers what isn't working, and I make it work.

Be ruthlessly iterative.

If I can't get a piece of work released in two hours, I cut the scope down to something achievable, and iterate on that.

It's worth noting that this is the ideal, and I don't always succeed at cutting down scope to exactly two hours. Over time I've realised that with how my brain works, I enjoy shipping early versions as quickly as possible, and building out the functionality once it's deployed (behind a feature flag).

Waiting until the entire feature is built before deploying completely saps my motivation in comparison, and I find myself easily distracted when building this way.

Lessons

Read a few books, and start building

I read dozens of business books when I wanted to get started, mainly from not wanting to repeat mistakes that others have made.

Sometimes though, you need to make mistakes for yourself.

As an example, it took me getting on the front page of Hacker News, having 6000 people visit my landing page, a few hundred people attempt to sign-up, and only single-digits making it through to the app for me to realise something might be wrong.

I had something like a 75% drop-off rate on my sign-up form alone. I got it down to 50% just by adding an extra OAuth login provider.

If I had to do it all again, I'd start with only three books:

The Mom Test by Rob Fitzpatrick
Deploy Empathy by Michele Hansen
Badass: Making Users Awesome by Kathy Sierra

and if you need specific detail on building and running a SaaS, The SaaS Playbook by Rob Walling.

Solve pain, don't try to sell a subscription

The product's goal is to solve your customer's pain, rather than sell subscriptions to your SaaS.

This is a mindset shift from "I'm just going to keep building features, they'll come eventually!" to "I should be helping my users solve this annoying problem in their job"

Building a SaaS is just one of the ways you could be solving their problem. There are other ways you could help, like recording screencasts, writing docs, articles, books, running workshops, providing code samples, etc.

Ship small, ship often

People will suggest you should build particular features to improve your product.

They'll never use those features.

They're probably just trying to be helpful, and saw a similar feature in another product. Because you're new to running a SaaS, you'll be excited that people are actually talking to you, and rush out to build that feature for them.

I'm not going to tell you not to build the feature (that's the advice I was given, and I built unused features anyway). You should ask how they would use the feature, ask other customers how they deal with the problem, build the smallest possible version of that feature, and see how the rest of your customers use it. You don't want to be building snowflake features only one person uses.

It stings a lot less to remove a feature no one wanted after spending a few hours on it, rather than a few months.

Ship first, worry about scale later

In the first iteration of OnlineOrNot, I didn't optimise the architecture at all.

There was actually a bug that limited the total number of uptime checks the system could handle to around 100. I also didn't have proper error screens, so when users ran into that issue, all they saw on the screen was:

Error!

Not a great look.

At the same time, I prefer being embarrassed by incomplete UI than building things people don't need. There was never a guarantee that OnlineOrNot would attract thousands of users, it could have ended up as another SaaS I built only for myself.

My immediate solution was to upgrade my database to a higher tier, increasing the number of uptime checks that could connect to the database, and in the meanwhile I got to work on rearchitecting the product.

A few hours later, I had a solution in place that could handle millions of checks per week on the smallest AWS database, and made that error screen look a bit more professional.

Have an early-access program

Shipping early is incredibly useful. Early on in your product's development, almost all users that sign up are expecting rough edges (especially if they've seen your unpolished landing page).

As time goes on, you're going to get folks expecting a mature product, so you can't just keep shipping imperfect features to your entire userbase.

My solution for this was to add a checkbox in each user's account with the label "Join the Early Access Program". Folks that opt in get to see OnlineOrNot's latest features before they're ready, in exchange for patience and feedback.

Build a free trial as soon as possible

The common wisdom these days is to not even bother with a free tier - it's too difficult to get right. When I started though, a free tier was a great way to attract people and get them talking about your product.

The thing is, you still need a way to let them sample "the good stuff", especially if the free tier is significantly less useful than your paid tiers.

It took me 11 months to realise I should build an onboarding flow that ended with asking if folks wanted a free trial. Particularly, it asked:

Do you want to start a free trial?

What it was actually saying was:

Do you want to experience OnlineOrNot's best features for 14 days before deciding if it's worth your time, or spend months with a product that has the good stuff disabled, unsure if it'll actually solve your problems?

I eventually decided to experiment with defaulting all users to a free trial first, so that everyone could experience the entire product first. This one experiment more than doubled OnlineOrNot's monthly growth rate.

It turned out that starting the business relationship with "this is a paid service, you'll need to add payment details to continue getting the good stuff" helps the business significantly more than "this is a free service, if you use it a lot, you might have to pay for it".

Docs are the product

Back when I started, folks used to say that "developers don't read documentation".

This turned out to be bullshit.

Some of the early customers in my ideal customer profile (ICP) came in praising OnlineOrNot's documentation, and I doubled down on it since. I even went as far as building my API docs from scratch to have full control over the user experience.

Back when I had product analytics, I noticed people would struggle to do something in OnlineOrNot's UI, get frustrated, check the docs, and one of two things would happen:

They would find the exact feature they're looking for in the sidebar, and keep using the product for a long time
They would not find what they were looking for, not create any checks, and just churn

In short, successful use of the docs drove retention.

Build for mobile

Contrary to popular belief (for B2B SaaS), folks actually work from their phones, and I think the rate is increasing.

Something like 50% of users start their journey to my product on mobile. They would quickly create an account, add a few pages to monitor, then eventually get on their laptop/desktop to review their checks from time to time.

For the first 6 months I didn't support mobile well, and folks that signed up on their phone churned rapidly. I eventually took the time to build responsive views for mobile, and new mobile users stuck around.

Ask people how they found you

One of the most valuable code changes I made halfway through the first year was asking people as they signed up: "How did you find out about OnlineOrNot?"

You need to know where your users are finding you.

There are dozens of marketing channels you could be using to attract potential customers. You only have a fixed amount of attention, so if you find a channel that's working more than others, you need to focus that attention on that channel until you notice diminishing returns.

I don't use invasive analytics

When I started, I integrated with standard SaaS product analytics software that most big SaaS products use. They tend to have features like session recording, where you can see exactly where their mouse moves in your product, and funnel tracking for working out how many users make it the whole way through from landing page to using your product.

This turns out to be useful in bigger companies. You have stakeholders to align with your vision of how the product should be built, it's easy to point to some data and show that version A resulted in sign-up uplift over version B.

The thing is, most products don't get enough users through the funnel to prove that the result you see is actually because something is better, rather than random chance.

As a solo founder with only two hours to spare every morning, I just didn't have the time to go through all that data and try to convince myself something. Instead I have an "inner-circle" of users that I DM for a vibe-check on features and problems in the product, and build things by taste.

Talk to potential customers, even if you think you have nothing for them

I was contacted by a CTO early on, asking if OnlineOrNot supported some particular feature.

My normal reaction would've been to just say "sorry, no" and leave it at that. Out of curiosity I started asking what pain they're trying to solve, I also asked the inner-circle users if they ran into this pain too, and what they'd like to achieve with the feature, and I told this CTO how I figured I would build it.

They signed up to a paid plan the next day, they've been customers ever since, and the feature gets used by other customers too.

You don't get to spend as much time solving the problem as you think

Of all the time I spent programming in the last four years, significantly less than half went to actually solving the problem I wanted to solve (knowing if a site is down, and alerting folks when that happens). The majority went to building a SaaS platform around that problem.

SaaS platform things you didn't even realise you'd need, like multiple types of authentication and user management, trials, onboarding, recurring database jobs, team management and invoice management, lifecycle emails, and more.

A lot of folks outsource this type of work (and I do! If Stripe didn't exist, I probably wouldn't be selling a service nor using subscription-based billing), but there's always stuff you don't feel comfortable outsourcing, or that you handle differently, so you need to build it yourself.

Pricing is hard to get right

Price too high, and you'll either have churn from folks who expect your app does everything or completely kill your sign-up rate. Too low, and you'll have customers that demand you rewrite your app just because they gave you $9.

Refund the difficult customers, raise your prices, and move on. Be prepared to experiment a lot with pricing, especially early on and as you build functionality.

Don't tunnel-vision your MRR

Tracking your MRR is a crap way to measure how you're doing as a business.

Things you did weeks (if not months) ago will affect your MRR today, so you won't really know if pricing changes work until you've already got a decent number of customers going through different stages of their customer journey.

Depending on your product, it could take up to 60 days for a user to go from signing up for the first time, to entering their credit card details.

Find another success metric to figure out if people are actually using your product, and whether it's bringing them value. Things like number of images generated, or number of form completions, for example.

Never give away "unlimited" anything

There will always, always be a whale customer for whom an unlimited amount of your value metric for $250/mo will be the deal of a lifetime. Generally speaking, never offer unlimited anything, especially if it costs you additional money for each thing created.

Lifetime deals fall under this advice too.

You aren't "finding users" for your product, you're finding people that expect you to build exactly the feature they want from you, years down the line, for that $100 they gave you once. Of which you likely only saw 30%, if you used a third-party to run the lifetime deal on their marketplace.

Rate limit your paid resources

If you call any sort of paid API (whether it's AI, sending SMS/email etc) as part of your service, you're going to want to rate limit calls to that service.

But my users are paying me for this service, shouldn't they be able to use it as much as they want?

Of course there are exceptions (and it depends on your Terms of Service), such as if an extremely large company starts using your service, but generally speaking, this will save you from a large unexpected bill at the end of the month, or being labelled a spammer by your vendors.

If someone genuinely needs to use your service at an extremely high rate, they'll get in touch.

This particular insight comes from the time OnlineOrNot sent thousands of SMSes to a web agency when the one server holding hundreds of their WordPress websites started running out of RAM.

Stop trying to explain everything on one page

If you try to be everything to everyone, you'll end up being nothing to no one

I think this applies particularly well to copywriting for landing pages.

As I built additional features into OnlineOrNot, I would try add additional sections to my main landing page, and it ended up an incoherent mess, diluting the overall message. I would have folks emailing me to ask if I supported sending alerts to Slack, when it was the second feature I built for OnlineOrNot.

Instead, by breaking up each feature into its own landing page:

I can take the space to explain each feature, without diluting the message.

It's hard to bring in more traffic, easy to change what your current traffic does

Getting noticed on the internet is a long, slow game.

Eventually over months (if not years), if you're consistent at quality content marketing, the number of readers on your articles will grow from 1-2 a day, to a few hundred per day.

Increasing the number of people landing on your site isn't particularly easy.

On the other hand, what people do once they land on your site is entirely within your influence, and something you can change today (such as adding an additional OAuth login provider to your sign-up form, that I mentioned earlier).

Competitors don't really matter

You might have noticed I haven't mentioned anything about competitors here, despite operating in a highly competitive market.

The truth is I don't think they change much.

Sure, there are more "table-stakes" features that customers need before they'll even consider using you, but the real competitor is a lack of awareness of your product, more than anything.