24
14 Comments

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.io Screenshot

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 Growth

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.
Stripe Dashboard Showing Revenue

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:

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:

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!!

  1. 1

    Great interview. May I translate this article into Japanese and post it to my personal blog?

  2. 1

    Great information! I'm curious about the process of rising prices. Did you rise only for new customers, or also existing ones? If for existing ones too, did you set a transfer period or was it immediate? And further, what did you email your existing customers in that situation?

    1. 1

      Good question. It was only for new users. Any existing use got to keep the plan they were on.

  3. 1

    Been using Cronitor.IO since 2015. Highly recommended!

  4. 1

    I subscribe to "worse is better" (WIB being a different flavor of JIT), so that part really resonates.

    https://www.youtube.com/watch?v=X45YY97FmL4

  5. 1

    Great interview! When/How did you guys decided was the right time to leave your jobs? - Or in case you haven't yet, when will be the time?

  6. 1

    Thanks for sharing guys! I assume you guys are two engineers - how did you handle the design/UI side of things? Is it something that comes naturally for one or both of you, or did you outsource?

    1. 1

      Thanks! A friend of ours, the awesome https://twitter.com/gregsqueeb designed our current homepage and pricing page which gave us a nice color palette to follow. We both worked hard to get the dashboard UI to where it is today (the first version was embarrassingly bad). During our last push at updating it we realized there are still a few deficiencies, and are planning some further updates soon...

  7. 1

    What a great interview! I fully subscribe to the JIT startup mentality, but my first question is has that ever come back to bite you? Secondly with the move to expand across use cases, are you considering abandoning "cron"itor name and brand? And finally as designers, we really appreciate the quality of your website (most dev services look like dev services). Job well done on the site and docs!

    1. 1

      Great questions - I'll answer the easy one first. We are defintely considering rebranding as we expand our offerings. There are two ways we are considering going about it. One, should we have a single platform with a different name that can cover a lot of types of monitoring. Or, two should we split out our healthchecks monitoring to be another standalone service powered by the same backend, but with a different interface/name. Jury is still out, and we would love to hear opinions!

      The JIT mindset has definitely bitten me a few times in my career, but having a partner on Cronitor has helped mitigate some of that. For example, while we both subscribe to this philosophy, Shane is a much better developer than I am and tends to build more robust systems from day one. A couple of times early on I remember thinking he was spending too much time early on with things like detailed logging, only to have that come back and save us a ton of grief later down the road.

  8. 1

    I should start using Cronitor. Are you offering some kind of Indiehackers discount or deal? ;)

    The Breaking Into Consulting job alerts system is a series of Cron jobs (to monitor various freelance jobs RSS feeds).

    1. 1

      We'd be happy to offer a discount for anyone coming from IndieHackers. We don't have a discount code system (JIT ), so just email us after signing up and we can give you a 10% discount.

  9. 1

    This comment was deleted 3 years ago

    1. 1

      When we launched we had a free plan with a paid upgrade option. No free trial. In 2015, we built a free trial and discontinued the free plan for a few months. First we tried no card up front for the trial, then we tried card up front. In the end, we added back the free plan and kept the free trial to a paid plan. We also stopped segmenting on features at this point, adding things like slack, API access and web hooks to the free plan.

      In the end, we added the free plan back for several reasons:

      • Our product got better, and we thought paid conversion would be genuinely improved by letting people use the thing.

      • Getting users signed-up and into our drip/marketing emails with as low a barrier as possible.

      • We have definitely had users upgrade from the free plan after weeks/months/years. Hard to say for sure if they would've come back after an expired trial, we have had some users from the free trial era reactivate.

      Client APIs... honestly these started appearing almost as soon as we released an API (6 months or so after launch). We have not collaborated on them at all. We do plan to send pull requests to update them all to the latest versions of our endpoints, but for now we continue to appreciate the generosity and work of our users! https://github.com/cronitorio/django_auto_healthchecks is our first official API client.

      We tried to provide a simple, browsable restful JSON api to enable users to do most things easily, but clearly there was a desire for an API client. I don't regret that we didn't build them early on, because we built things that I think were more valuable, but it would've been easier for our users had we done that work up front.