The Market Lacked the Tool We Wanted. So We Built it Ourselves.

Hello! What's your background, and what are you working on?

Hi! My name is Mattias Geniar and together with my partner Freek Van der Herten we founded Oh Dear!, a new tool focused on monitoring websites.

We both got fed up with existing tools that didn't fit our needs precisely. Most came close, but there was always something — whether settings or design choices — that we just didn't like. Being engineers, the obvious next step was to just build it ourselves!

Oh Dear! launched in private beta earlier this year and has been running in production for a few months now. It's already generating over $1,500 per month.

How did you come up with the name?

Back when we were brainstorming our featureset and our approach, we spent most evenings in a café in Antwerp called Paters Vaetje. They serve a nice tasting beer there called Moeder Overste, which has the logo of a nun.

Freek then asked the question, "What would a nun say if her site went offline?" The answer: "Oh Dear!"

It gave us options for the site copy, the logo, etc, and we decided to run with it!

What motivated you to get started with Oh Dear?

Both Freek and I look at the monitoring problem from different angles. I'm a sysadmin at a managed hosting provider where it's our job to keep things running smoothly. Freek is a partner at a Flemish web agency focused on custom-made applications.

Obviously, we both care about our websites being online and operational. From Freek's standpoint, he wanted to know the state of each page, if it contained mixed content (because some of it is user-uploaded), if certain pages would generate HTTP/500 errors, etc. My focus was the general health of the servers and the HTTPS stack — are certificates about to expire, are we still using secure TLS ciphers, what's the response time of the sites, etc.

When we did our own search for monitoring tools that combined all of the aforementioned features, we came up short. Some came close, but ultimately made tradeoffs that we didn't like.

We created an MVP in a few months and started using it ourselves. It quickly replaced our own (commercial) monitoring solutions and gave lots of insight into our applications that we didn't have before. If there's user-generated content involved in a site, it's so easy to create pages that are fundamentally broken or contain HTTP elements in an HTTPS context, which a browser blocks. We gave some of our friends access for testing purposes, and their reactions and enthusiasm were enough for us to validate our idea. We knew we had something special.

What went into building the initial product?

What gave us the spark (pun intended) was actually a product release by the founder of Laravel, a popular PHP framework, called laravel Spark. It's a custom framework that includes the boilerplate for starting your own SaaS. Out of the box, it introduced user management (activation, lost passwords, and so on), handled invoicing and online payments through Stripe, etc. Spark basically did everything we didn't like about building our own SaaS, what we consider to be the boring stuff.

We wanted to created a monitoring solution, not spend half our time on user management, implementing coupon codes, handling payments, and figuring out how each country's VAT rules work. We got all of that by using Spark as our foundation. That alone saved us months of work, which made the MVP ready in less than four months.

Since we both have a PHP background, we coded during the night while our day jobs gave us the inspiration for all the features we wanted and, importantly, all of the features we hated about the existing tools.

Once we had a working product, our started focusing on usability and design. We come from the Laravel space, where the culture has shifted to appreciate design and style a lot more than it used to in the open source world, so we couldn't just launch an app using bootstrap since it would look too much like a prototype. We wanted an application, not just a work-in-progress tool.

Early on, we invested in a custom made design. This was our biggest cost, but our wisest budgetary decision. The design paid for itself in three months. People loved the style, the look and how it feels — something we couldn't have done ourselves.

The new design was also built using tailwind, a new CSS framework. This had the added advantage of giving us the ability to promote the site through their channels, as they were looking for new cases to show off the potential of the framework.

How have you attracted users and grown Oh Dear?

They say the social and organic growth is the healthiest strategy. So far, it's been the only one we've employed. Both Freek and I are active on Twitter, speak at conferences, and have a popular blog. Up to this point, that's all we’ve used for promoting Oh Dear!

Before we launched we hyped the service through social media. We showcased screenshots of some of our code, the new things we were building, our test suite, the design teasers, etc. All of that was to drive a pre-launch mailing list. We ended up with well over 500 users on that mailing list, which gave us a healthy launch platform to build on.

Understanding our own shortcomings and strategizing with them in mind was vital for a viable product and a successful launch.

Everyone advocates the use of mailing lists, and I've been skeptical for a long time. But the truth is, it worked. We had a nicely designed landing page that teased the product and the features (I think this was key), and we saw every sign-up to our mailing list as a validation that there was demand for what we were building.

In total, I think only 10% of those on the list converted to actual paying users. That was a lot less than we expected, but talking to other founders it seems to be in line with the desired ratio. Many users want to try it before buying, and many more simply expected a free version without ever having the intention to pay anyway.

From then on, growth was mainly through word of mouth. Right now, we're in the process of doing actual marketing. However, as two hard-core developers, the marketing side is something we need to get more comfortable with.

What's your business model, and how have you grown your revenue?

For Oh Dear! it's pretty simple: there's no free version, you pick a monthly subscription that determines how many sites you want to monitor. You can try it out free for 14 days, no credit card upfront, to see if you like it. There's no distinction of features or data retention, these features are the same across all plans. We wanted simplicity through and through, and felt that should be reflected in our subscription plan as well.

We recently added a referrals system to our service, but so far that hasn't generated any meaningful leads. I think many people are tired of seeing this kind of promotion (think of the typical Digital Ocean reflinks) and it may no longer be fashionable to do.

When we finally launched publicly, we got almost 20 sign-ups from our mailing list announcement. Seeing that money come in via the Stripe mobile app was very exciting. From then on, we've seen a steady increase to the point where we are now making $1,500 per month, and continuing to grow every day.

Because of our choice to use Laravel Spark as the foundation, Stripe made most sense as a payment processor. We didn't research this, it was the default option in Spark and we just went with it. And I have to admit, Stripe has been a great asset. Between the built-in coupon method they use (for one-time or recurring discounts) and the easy options to refund payments, it's an all around great payment provider compared to anything else out there.

Just last month, we launched a feature to do annual payments as opposed to monthly payments. More and more users were asking for it, especially for our small plans since it can be a bit annoying to have to file and process a $5 invoice every month. Yearly plans simplified the process. As a result, our revenue has gone from steady and predictable to wild and varying, since not only customers choosing smaller plans opt into yearly subscriptions, but bigger users do as well. Which means we saw a surge of money come in, but our monthly revenue has since decreased since those users all paid up front.

We debated this decision for a long time, weighing the pro's and con's of monthly versus annual billing. For our purposes, We determined that it didn't matter that much. Our invoicing and accounting is automated and we don't pay per invoice, it's all the same regardless of how many invoices we’re sending out to any given customer.

In the end, we went with what was best for our users. We wanted to appeal to their interests users and show that we were listening to their feedback, so we chose the option our users were advocating for, even if that means that our income is slightly less predictable. That's our concern, not theirs.

What are your goals for the future?

Well, we're still two PHP developers. We don't have a business target we want to reach. At least, not yet.

We just want to add more features that we ourselves want. For the short term, that means additional SSL monitors, extending our API, and investigating the options to do server-side monitoring as well (like disk space and CPU load).

We believe in slow and steady growth. There's no grand plan for selling our app and retiring, we're after the dream of passive income. Except it's not passive — it requires work, every day. I think passive income is often misinterpreted as "I want to be independent and just make a living doing my own thing every month." Though independence would be nice, we're really after the latter. We love building, coding, and shipping, so why would we stop doing that?

What are the biggest challenges you've faced and obstacles you've overcome? If you had to start over, what would you do differently?

What we focused on early on — despite everyone warning against it — was to optimize for scale.

Not because we thought we'd get thousands of users on day one, but because of the way our SaaS is structured, scale is achieved pretty quickly. If we get 10 clients that each monitor 100 sites, that means we're running over 1,000,000 "jobs" per day. A job is monitoring the uptime, checking the certificates, validating the chain, etc., and it quickly adds up. Thankfully, we thought about this design at day one and used message queues and async processing straight away.

It does add complexity to the codebase and makes testing a bit of a challenge, but if we hadn't done that we couldn't scale beyond a few 100 users.

Have you found anything particularly helpful or advantageous?

The smartest decision we made was not to go it alone. We teamed up and that gave us the ability to motivate and challenge each other.

In every SaaS launch, there are periods with higher levels of activity and periods of burnout. There are times when you just want to give up because it seems impossible or daunting. Because we had each other, we had the motivation to keep going. We could revive each other by asking "Hey, how's feature X going?" Neither one of us could have built the product alone and it's been a lot more fun building it together than going solo, which I did when I launched my first SaaS called DNS Spy.

What's your advice for indie hackers who are just starting out?

Find someone to keep you accountable.

The smartest decision we made was not to go it alone. We teamed up and that gave us the ability to motivate and challenge each other.

Whether it's a partner to work with or a Twitter post that says "I'm building X!" so others can check in on the progress, it helps to know that a) others care what you're building and b) someone can give the nudge once in a while to pick up the pace again.

Additionally, the wisest decision we made was to pay for a proper design and layout. We're good at coding, bad at designing. Understanding our own shortcomings and strategizing with them in mind was vital for a viable product and a successful launch.

Where can we go to learn more?

Oh Dear! itself can be found on ohdear.app. Freek is active on Twitter as @FreekMurze, where he regularly showcases code snippets, testing suites, design choices, and more. He's pretty open about about his work. He also blogs about PHP and Laravel at murze.be.

I'm @MattiasGeniar on Twitter, where I focus more on the Ops and security side of things. Some more long form content can be found on my blog, ma.ttias.be.

If you have any question, we're both pretty responsive, just reach out!

We've got plenty of new ideas for features and tools, but our number one source of feedback and product ideas comes from random Twitter conversations. If there's something missing or you have a frustration with other monitoring tools, we actually do love to hear about it!