What I learned running a SaaS for a year

This time last year, I showed the internet a little prototype uptime checker I built using Next.js as the frontend, with services running on AWS Lambda. I gave myself one week to put it together.

Update: I've been running this business for over three years now, if you're interested to see how it's going, check out lessons from my third year running a SaaS .

The gist of my approach is as follows:

I started with a single Lambda function that checks if static websites were still online, added an email alert if it's offline, wrapped authentication around it, integrated Stripe, and shipped it. Throughout the year, I kept adding features.

My trick for launching into 200 competitors providing the "same" service and still getting customers?

• I work two hours a day, every weekday on OnlineOrNot, and no other side projects. I managed to keep this going for about 10 months this year (with a cheeky 2 month burnout in the middle).

• I focus particularly on features that solve customer pain (and I ask my customers what that pain is)

• I'm ruthlessly iterative. If I can't get a feature done in two hours, I figure out how to cut scope down to a two hour block, and ship that. Then iterate on it.

Here's what I learned after a year:

Table of Contents

• You're solving a problem, not selling a SaaS subscription
• Docs are part of your user experience
• Build for Mobile
• Ask people how they found you
• Use analytics, set-up funnel tracking
• Sometimes you need to make your own mistakes
• Pricing is bloody hard to get right
• You probably focus too much on MRR
• You still need a free trial for paid tiers
• It's hard to bring in more traffic, easy to change what your current traffic does
• Content marketing buys you time
• Ship small, ship often
• Ship first, worry about scale later
• You don't get to spend as much time working on the problem as you'd think

You're solving a problem, not selling a SaaS subscription

When building a product, it helps to think from the perspective of your customers, rather than your own goal of selling subscriptions.

This takes you from a mindset of "I'm just going to keep building features, they'll all come eventually!" to "I should be helping my users solve this annoying problem".

SaaS is just one of many ways to solve a problem. You should be looking at all the ways you could be helping, whether that's screencasts, docs, articles, books, workshops, code samples or software.

Docs are part of your user experience

People often say "Developers don't read documentation" - I think that's only partially true.

They don't read, they skim the headings.

In my experience, some people would try to figure out how to do things themselves in OnlineOrNot's UI, get frustrated, check the docs, and either one of two things would happen:

1. They wouldn't find a way to do what they were trying to do, and they'd immediately churn
2. They'd find the page they were looking for, jump to the heading, and do the thing

Successful use of OnlineOrNot's docs drove retention - so I treat it as part of the core product now, not as an afterthought.

Build for Mobile

Contrary to popular belief (for B2B SaaS), people actually work from their phones.

Something like 50% of traffic to OnlineOrNot.com comes from folks on mobile. They tend to 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 about 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 now new mobile users are sticking around.

Ask people how they found you

One of the most valuable code changes I made this 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 channels you could be using to attract potential customers, and it's useful to know whether to double-down on paid ads, content marketing, or shitposting on Twitter to bring in users.

Use analytics, set-up funnel tracking

Your marketing funnel helps you work out the health of your business. While it's nice to see how many people visit individual pages, it's even better to see how people flow across multiple pages.

When I say marketing funnel, I mean tracking the flow of people that visit your home page, eventually making it to your sign-up form, and finally making it inside the actual product. It helps you diagnose problems with your marketing copy, the sign-up form itself, as well as any onboarding you may have before the user actually sees your app.

You don't need gross privacy-invasive tracking to achieve this by the way - I use a basic privacy-first web analytics service (and have no cookie banner as a result), and it works fine.

Sometimes you need to make your own mistakes

I read quite a few business books, 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. With a bit of A/B testing, I got it down to 50% just by adding an extra OAuth login provider.

Pricing is bloody hard to get right

Price too high, and you'll have churn from folks who expect your app does everything. 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.

You probably focus too much on MRR

Tracking your MRR is a pretty lousy way to measure how you're doing as a business early on.

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.

I find measuring your daily active users, or some sort of "success metric" for your customers (like pages checked, images generated, etc) is more helpful than MRR. It lets you figure out if people are actually using your product, and whether it's bringing them value.

You still need a free trial for paid tiers

While a free tier is a great way to attract people and get them talking about your product, 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 probably build an onboarding flow, and start offering free trials. 95% of new users pick a free trial of the pro tier, even though I offer a free tier.

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).

Content marketing buys you time

Investing in content marketing gives you the option of letting the business run itself/coast for a while.

Throughout the year, I'd have an occasional article go viral and bring in tens of thousands of visitors over a month, if I did absolutely nothing, about 1500 people would still visit the site organically for the articles I had written.

This was particularly useful for when it's a pandemic and I was having a bit of a burnout while moving across the world to live in France.

Ship small, ship often

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

They'll probably 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.

Each uptime check would manage its own database connection, meaning as more users found the service, the harder it would be for additional users to use the app. I also didn't bother making decent error states, so new users would see this while the database was busy:

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.

I ended up reworking the architecture to handle millions of checks per week on the smallest AWS RDS instance, as well as cleaning up that error screen:

You don't get to spend as much time working on the problem as you'd think

Of the time I spend programming this year, I'd say half of my time went to actually solving the problem I wanted to solve (knowing if a site is down, and alerting folks when that happens). The other half 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, team management and invoice management, lifecycle emails, and more.

You can outsource a lot of this (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.