Identifying a Simple Problem and Growing a Solution to $6000/mo

Hello! Tell us about yourself and what you're working on.

My name is August Flanagan, and I'm a software developer in Berkeley, California. I've been working on Cronitor — a tool to monitor cron jobs/scheduled tasks, web services, and daemons — with my co-founder Shane Harter for almost three years now.

Today we're making around $6000/month from the service.

How'd you come up with the idea for Cronitor?

In March of 2014 I was working at a really small startup as the only full-time engineer. We were working on an interesting real-world problem (managing/routing a fleet of delivery vehicles), and we were shipping software every day to keep drivers on the road.

We started relying heavily on cron for things like checking driver progress, processing orders, and delivering notifications to customers. We were so busy in the real world that it kind of caught me by surprise how quickly cron had become a single point of failure for us.

I knew I needed to start monitoring these mission critical cron jobs. One morning I spent about 10 min staring at the Monit docs and decided there had to be an easier way. I started looking around for a SaaS tool that would notify me if my cron jobs either stopped running, ran for too long, or started overlapping in ways that would constrain server resources. I found a couple of tools that solved the first problem, but none that solved the others.

That night I happened to mention this to my wife (also a developer and founder) and she said, "Oh my God! I just found out that my database backup cron job has been failing for the last two months. I would absolutely pay for that tool."

That got me excited, so I texted Shane about the idea, and he immediately brought up several times he had seen critical cron jobs fail silently in his work as an engineer at a couple large tech companies. Based on that we decided to build a prototype.

Cronitor's website today.

What did it take to build the initial product?

We were both working full-time jobs at startups and didn't have a lot of free time. This forced us to be draconian about what features would make it into our MVP (minimum viable product) and what could be punted.

We decided that the bare essentials required to make this a useful tool (and to test the viability of it being a business) were:

1. Creating an account.
2. Creating a monitor: defining rules and choosing between email or SMS alerts.
3. Sending alerts if a monitor failed.
4. Collecting credit card information for paid accounts.

The basics were quite a bit of work, but we managed to cobble most of it together in one long weekend. We then spent a few nights here and there over the next 8-10 weeks before we decided that it was ready to be shared around with a few friends.

I think it's also worth calling out a few of the things that didn't make the cut:

1. Editing basic account info. (It was almost two years before I added a form to update your email address.)
2. Viewing a monitor's ping history/duration information.
3. Creating subscriptions for paid accounts. (We did it manually in the Stripe dashboard for our first 20 or so paying users.)
4. Sending automated emails. (We would manually email each new signup.)

How did you grow Cronitor's customer base after launching? Were any marketing strategies particularly effective?

We knew that getting to launch was just the first step, and that we needed a plan to attract our first few users. The problem is that we were building a niche tool, so it's not something that a lot of people would just try out on day 1. (Even moreso because the product was pretty rough.)

With this in mind we had a guerrilla attitude towards our initial marketing efforts. In other words, we were going to do things that didn't scale in hopes of getting just one or two paying customers in the door.

Our official "launch" was an obligatory Show HN post on Hacker News. It managed to appear on the front page for an afternoon, and we got about 25 sign ups from it. Only a few of those people actually created a monitor, and none of them signed up for a paid plan.

After the initial burst of sign ups from HN we did several things in order to keep getting a trickle of new users coming in:

1. Answered StackOverflow questions. There were a number of questions related to cron job / scheduled task monitoring, and we believed that Cronitor was a compelling solution to many of the questions being asked.
2. Added a link from an open-source library. Shane maintains a modestly popular library for creating daemons in PHP. Cronitor is quite useful for simple daemon heartbeat monitoring, and this was a low effort way to cross promote it.
3. Created a Stackshare page.
4. Submitted Cronitor to Startupli.st. Nick Frost used to run this great site that's sadly not around anymore. It was a roundup of new startups/micro-service that had a decent newsletter and Twitter followings. Being included in their weekly email is how we landed our first paying customer.
5. Submitted Cronitor to One Thing Well. Similar to Startupli.st except focused more on developer tools/software. It took a couple of months before they published us, but we got at least two paying users from being included in their daily email. It felt like a real turning point in validating the idea. We had taken a bit of a break from working on it, but those signups got us back into working on it a few hours/week.

Those efforts plus posting on a few other small forums and emailing friends landed us our first 6-10 users.

One thing that we'd discussed early on (before we'd even written a single line of code), was that we were building the type of product that people never think about until they have an acute need for it — i.e. you only go looking for this type of thing once you've been burned by a failed cron job in production.

With this in mind we set out to write high quality docs that would help our SEO. We started writing docs that focused on using Cronitor to solve specific problems that people would be searching for like monitoring cron jobs, monitoring Windows scheduled tasks or cron job time tracking.

We knew that this wouldn't be an overnight win, but the more time we have put into our docs the better we have done on Google. For the past two years organic search has been our best acquisition channel.

How does your business model work? What's the story behind your revenue?

One of the things that really excited us about Cronitor was that it was clear from the beginning that we would sell it as a SaaS product. We would segment based on number of monitors, number of users, and a few other features. As users of the product ourselves we felt like we could picture the different types of companies that would pay for these different plans.

It was incredibly important to us to launch with paid plans on day one. We both believed in the utility of the product we were building, but we weren't building it just to build the software. We wanted to validate that this had potential to be a real business, and the best way to do that is to get someone to enter a credit card.

We spent a lot of time debating how we should price our product. We didn't want to price too low, but at the same time we were launching a pretty bare bones service, and we wanted to attract early customers. Ultimately, we decided to launch with three plans: $6.99, $19.99 and $49.99. Our first few users were primarily on the $6.99 plan — we were thrilled when our second organic sign up picked the $19.99 plan.

After about 6 months and some improvements to the product we decided to raise our prices to $9.99, $24.99, $49.99. People kept signing up, and we added several frequently requested features (teams, PagerDuty, Slack integrations), so we decided to raise our prices again to what they are now $24, $69, $149.

In the graph below you can see where those last price changes took place (June 2015) and that revenue starts growing quite a bit faster after that:

Revenue, 2014 through 2016.

Raising prices had another impact on the business as well. It changed the type of customers that were signing up. At the lower prices we were getting a lot of hobbyists or small dev shops signing up. While we'd be happy with any customers we could get, we noticed a few things changed once these users (who tended to be more price sensitive) stopped signing up as frequently:

1. Our churn decreased — I attribute this to our users being more established businesses now, and ones who are less likely to focus on cost savings by cutting a couple hundred dollars per year.
2. We actually receive fewer complaints about our pricing — it seems counterintuitive, but when we first launched we would receive a couple of emails per month criticizing us for charging so much for such a "simple product". This was a bit demoralizing, and really made us question our pricing many times.
3. We receive fewer requests for custom plans/discounts — again I think this goes back to how the price changes shifted who our customers are. If you're an engineer at a large company and you need team support you're not going to blink an eye at selecting the team plan. But, if you're a small shop or an independent developer who needs to cut costs you will definitely reach out and ask for a discount or custom plan. Note: Even though we have started focusing on larger companies, Cronitor remains free for anyone who needs a single monitor. Non-profits or open-source projects should absolutely contact us to arrange discounted/free access.

Revenue in January 2017, not including annual subscriptions.

As of January 2017 Cronitor is making ~$6,000/mo. Last year our profit margin was 77%. Since this is a pure software product it's not surprising that our primary expenses are software services as well:

• AWS ~$400/mo
• Stripe ~$300/mo
• Twilio ~$120/mo

We also pay for a few other services that make our lives easier like Pobox and MailChimp.

What are your goals for the future, and how do you plan to accomplish them?

One of the coolest things about working on Cronitor has been seeing people use it for things that we never thought about. Cronitor is a pretty simple tool, but its flexibility makes it great for throwing at problems that don't fit neatly into other monitoring solutions. For example, we have customers monitoring multi-step ETL processes, docker containers, dispatching notifications when consuming third-party webhooks, and notifying teams when a deploy or test suites finish running.

Seeing all these clever uses for Cronitor (and coming up with a few of our own) has made us expand our mission beyond just cron/heartbeat monitoring. Our goal is to be able to monitor anything that can either make or receive an HTTP request. To that end, a few months ago we added the ability to create monitors that will ping you (as opposed to you pinging us) aimed primarily at making it easier to monitor microservices.

There are a lot of similar tools out there for monitoring websites, but something that we really wanted for ourselves was a way to configure these types of health checks where our routes are defined — in our code. We've been working on a solution to this and are excited to be releasing a beta version of what we're calling "auto health checks" this week. We think this is valuable for any website developer, but is particularly valuable if you are managing a large microservice deployment with dozens or hundreds of endpoints.

Our first SDK is for Django which is the framework we know best, but we plan to release SDKs for Express, Rails, and Laravel in the coming months if there is excitement around this type of tool.

Aside from the above mentioned product goals, both of us have had the goal of having a steady income stream that could pay our mortgages. We live in the Bay Area where housing prices are pretty high, but we think we'll be able to pay our mortgages from Cronitor alone by the end of 2017. Getting to this point has made the extra hours and effort of maintaining a side project well worth it.

What are the biggest challenges you've faced? What would you do differently if you had to start over from the beginning?

One thing that I think surprised both of us was just how much effort the co-founder relationship takes. Shane and I had been friends for years, and worked together prior to starting Cronitor, but our relationship changed a lot once we became co-founders.

We've had to figure out how to disagree with each other in a productive manner, as well as how to set aside our egos in order to build something that we wouldn't otherwise be able to build on our own. If you had asked me what I thought our top three challenges going into this project would be, that definitely wouldn't have been on the list.

Now, having experienced this I've been asking founders/reading more about co-founder relationships and it turns out that this is a very common theme. Jessica Livingston has mentioned she spends a lot of her time mediating co-founder disputes during YC batches.

While I wouldn't do anything differently, I would recommend to anyone who is thinking about starting a company with a friend or colleague to not just focus on the product, but to make sure they're also investing in the relationship with their co-founder and making sure that they're having honest conversations as issues arise. The sooner these conversations happen, the more likely you are to be able to move beyond them.

What were your biggest advantages? Was anything particularly helpful?

I think the biggest advantage that we had early on was that we were building Cronitor for ourselves. When working on the MVP we never really had a moment of wondering "how will our users want this to work". We simply built exactly what we needed and started dog-fooding it as soon as we could.

Having a partner to work with has also been enormously beneficial. Cronitor is still a small business, but there have been plenty of times where having someone to talk through problems with, debug production issues, or to just commiserate with when something shitty happens has helped enormously. It's given us the energy to keep chipping away at improvements and new features over the past three years.

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

From day one we've had a mentality that we shouldn't work on anything that we can put off to later. We refer to this as the JIT mindset. It's helped us avoid pitfalls that we've encountered before or seen others encounter. Showing something you created to the world can be scary, and it's easy to justify continuing to work on something without shipping so that you can ship something just a little more polished. Try to avoid that.

It's also important to remember that it takes time to build a business. Nothing is going to happen overnight. It can take years to get a company off the ground. Pace yourself and remember that it's a marathon.

There are a few books that I've read that have really helped me frame how I think about creating a software product or problem solving:

• Four Steps to the Epiphany by Steve Blank
• Rework by Jason Friend and David Heinemeier Hansson
• The Power of Your Subconscious Mind by Dr. Joseph Murphy

Where can we go to learn more?

You can give Cronitor a try at cronitor.io. When we think we have interesting things to say about building the business, or dealing with interesting tech challenges we post them on our blog. You can also get in touch with us on Twitter.

If anyone has any questions for us please don't hesitate to ask in the comments. We'll try to answer anything/everything. Thanks for having us on Indie Hackers, Courtland!!