Why I built PULSE — a simple site and server monitoring tool for developers

mattkingshott profile image Matt Kingshott 👨🏻‍💻 Originally published at Medium on ・6 min read

The Pulse Homepage

Why I built PULSE — a simple site and server monitoring tool for developers

This is a reflective article based on Pulse’s journey from idea, through to realised product, through to released software.

Sign up for a free trial (without card) here: https://pulse.alphametric.co

The Background

While it might be easy to assume that Pulse was built for the market from the get go, the reality couldn’t be further from the truth. It started life as a tool to support another project I was building (and still am).

That project is going to use a provisioned server per client instead of a multi-tenancy approach. I could debate the merits of this decision for some time, but the overriding factor was just how complicated it is to manage the SSL certificates for multi-tenancy clients who want their own vanity urls.

I’m a Laravel developer using Forge for application deployment. Forge gave me everything I could need to do automated onboarding for new clients. Their APIs allow me to create servers, install repositories, obtain those all important SSL certificates, and more… the one thing that was missing though was server monitoring. Forge doesn’t include it.

Had I been using multi-tenancy, and a small number of servers, I probably could’ve cobbled something together, but dealing with hundreds of servers was just not a realistic option. I needed a genuine server monitoring tool.

The Search

A web search turned up the major players in the monitoring space… Nagios, Montis, DataDog etc. There are, of course, others, but this isn’t a full review of the competition, it’s about the insight / (biased) opinions that led to Pulse.

Let’s start with Montis :

The Montis Homepage

Maybe I’m being snobbish, but immediately I noticed a whole bunch of things that put me off using their product before I’d even looked at its capabilities…

  1. Dated design that looks turn of the millennium (both site and app).
  2. Far too much going on. What am I supposed to look at first?
  3. Illegible text over screenshots depicting hardware ~10 years old.

You might ask, why is that relevant? Surely, the product is what matters? Yes, in principle, you’re right. However, if they don’t bother to keep their site modern and clean, it begs the question, what is the state of their product?

Things get worse when you actually look at the server monitoring section itself. It’s a separate page (and perhaps tool) that provides you with this:

The “marketing” spiel for Montis

That’s it. Nothing else. It’s like Apple selling you a Mac and highlighting that it has a screen and a keyboard. Fortunately though, there’s plenty of detail in their pricing calculator (another immediate turn-off for me):

The “easy” pricing calculator

Okay, let’s move on and take a look at DataDog :

The DataDog Homepage

Definitely a lot better, but when moving to the product page, I experienced yet another major problem with server monitoring tools… complexity :

The marketing page for DataDog

There’s a lot going on there, and it is indeed very impressive feature wise, but as a developer, I don’t need 99.9% of it. I just want to know that my servers are online and not being overtaxed. I think this concept is best highlighted by DataDog’s ability to create custom dashboards. Based on my needs, I shouldn’t ever have to think of distilling the data because there’s too much of it.

Lastly, not to be outdone by Montis, DataDog’s pricing isn’t just a calculator, it’s an entire page all split into sections and subsections. The end result, at least for me, is a thanks, but no thanks!

Finally, we’ll take a look at Nagios:

The Nagios Homepage

More last century design and sub-divided product functionality, but even more intimidating is the pricing plans that they offer for their products. $2,000 as a starting price. That’s 200 times more expensive than the average virtual private server it’ll be monitoring!!!

Nagios pricing

To be fair, Nagios offer an open source option (and kudos as always for that), but that would mean a self-hosted, “you’re on your own route” that would require an extensive period of learning for anyone who isn’t already familiar with the tools. I simply didn’t have the time to set aside for that, as I imagine is the case with a lot of other developers. After all…

We’re programmers, not DevOps admins!

Reaching some conclusions

There are definitely options out there, but they’re either complex, ugly or hugely expensive. It’s clear that they’re targeting the enterprise space, which is fair enough. If I was a DevOps admin, maybe that’s exactly what I’d want.

So, what was the alternative? Do it myself! Build something that independent developers and small agencies would want. To meet those needs, I decided on a few key criteria that the system would have to be built around:

  1. It must be clean, singular, modern and not in anyway intimidating, while at the same time emphasising what it does and ONLY what it does.
  2. Absolutely zero confusion around pricing / determining plans. A customer should immediately know what they want... and it should be affordable.
  3. Setting up a server monitoring profile should be painless, bordering on the anti-virus philosophy of “set it and forget it”.
  4. Orient the app towards developers and not DevOps admins. That meant offering APIs and never assuming a customer will just know what to do.
  5. Offer the basics of monitoring for sites and servers. It’s about reassuring that infrastructure is online and running, not about micro analysis.

Something for the little guy

With that in mind, I began to develop Pulse. Along the way I discovered a great many things, which I took the time to document. If you’d like to check out the whole journey, see this article:

Creating Pulse — a simple site and server monitoring tool for developers

Three months later (including a month of beta testing), I had a product that was ready to go. It ticked all of the criteria I had set and I’d already had some outside validation that it was exactly what a certain kind of developer was in the market for. So, I went ahead and released it!

The Release

A few days ago, I launched Pulse on Product Hunt. It was a moderate success in terms of public interest, but a high upvote wasn’t the main priority for me. It’s easy to click the equivalent of a ‘like’ button. That being said, I wouldn’t have turned down a higher score 😄

What I really wanted to see though, was how many people actually clicked through to the site itself and created an account. If one goes by the upvote count, the figure was about 25%. That might seem low, but from what I’ve read, it’s on par with what to expect when you don’t have a huge online presence to support your product release.

Beyond release day

I believe very strongly that there is a real market for this kind of product, the issue is simply getting people to know about it. So, I’m looking into expanding my social media presence, posting articles like this on relevant sites and tapping into options like LinkedIn and Github Marketplace.

I’m also considering a paid referral program, so if you know someone with a decent number of servers who would be a good fit for Pulse, let me know either here, or on Twitter, and we’ll talk 😊

I fully intend to document my findings / progress, as I believe it’s something that other developers launching products may find useful.

Thanks for reading!

If you’d like to support Pulse, I’d very much appreciate an upvote on Product Hunt: https://www.producthunt.com/posts/pulse-ed0252af-6f72-49aa-b13c-ecceda38ff63

And if you’d like to take advantage of Pulse, please do head on over and sign up for a free trial (without card) here: https://pulse.alphametric.co

Lastly, you can follow me on Twitter here: https://twitter.com/mattkingshott

More to come…

The fruits of my labor

Posted on Apr 8 '19 by:

mattkingshott profile

Matt Kingshott 👨🏻‍💻


Founder. Developer. Writer. Lunatic. Created Pulse, IodineJS, Axiom, and more. #PHP #Laravel #Vue #TailwindCSS


markdown guide