Want to know how much website downtime costs, and the impact it can have on your business?
Find out everything you need to know in our new uptime monitoring whitepaper 2021



They say you always remember your first love. As a founder pushing your product live for the very first time you also remember those first customers.
There is quite simply nothing like it. Having built the product, and hoisted it into the world-wide-web, you sit back and you wait. You’re never quite sure whether anyone will sign-up. How long it will take. And then suddenly; actually far quicker than you ever anticipate, they do sign-up. And then another. And before you know it you think could this actually work?
When we started StatusCake just over three years ago it was very much the same. We started with an entirely free product – for the first few months no monetization at all!
As every customer came on-board we got to know them. We spent a long time talking to them. We had little else to do at the time! We probably learnt more about them – where they came from, their favorite soccer team; and of course being British, what the weather was like, than we did about their business! I guess, in hindsight, that’s what engagement is all about. Knowing your customer; building a personal relationship.
It’s fair to say that there was the good, the bad, and the ugly. Not our customers I hasten to add, but their experience of our product. I’d like to think that actually it wasn’t that bad for too many of them! We still have many customers from those first few months who are still very much with us. Thank-you – you know who you are!
But yes of course there were those in the early days who moved on elsewhere pretty quickly. I’d be interested to hear from anyone who tried us out in those first couple of months and has recently come back to us. What do you think? Is the personal connection there still? Is the product better? I’d like to think I know the answer on both!
But in those early months a few things still resonate.
Firstly that whenever anyone appeared on live chat (we used that from day one, nothing beats that immediate connection!), we would talk like friends. A cliché perhaps, but there wasn’t a soul we didn’t know and could talk quite happily and freely to. Secondly if any of them had a comment, however trivial, we would take that into account.
Those early users not only kept our spirits up with the great conversation and support, but they helped build our product. They shaped StatusCake into the product it is today. The product that over 35,000 customers have now come to rely on. As you become bigger and more successful it’s important to still try and keep that culture. The intimacy for want of a better expression. Seriously do you want to lose that and become a corporate just a couple of years down the line? Of course not!
Whilst it’s true that these days we can’t listen to every single idea about how to change the UI to cater for personal tastes (we’ve had some weird and wonderful requests!), we still roll out hundreds of features each year based solely on customer feedback.
So how do we ensure that we maintain that user connection? Here’s my takeaway two thoughts on this:
It doesn’t matter who you are. Whether you’re the founder, CEO or the intern you still do CS. Whatever your position at StatusCake.com you are not only expected to roll your sleeves up and do live chat but you want to. It’s not only important that you meet the customers and still feel that connection, but there’s nothing like live chat for quickly showing you the things that matter most. Ensuring you still understand the product and what it stands for. Where the problems are. Talking to customers quickly cuts through all the crap!
Far too many SaaS start-ups spend their whole time talking to their customers; often in some evangelical manner! Quite simply they don’t spend enough time listening.
We try and reach out to our users not only in a reactive way when they come to us on live chat, but also pro-actively reaching out at key stages on their journey with us.
When they sign-up we try to understand better how they found us and what they’re looking for.
When they’ve had a StatusCake account a few days we want to know that they’ve found the product experience intuitive. Were tests easy to set up, has nothing fazed them? And of course if it has, then helping them and finding ways to make that easier for them and everyone else coming after.
And key, at least in my mind. Once they’ve been there 30 days, 90 days and long into the future; not forgetting about them and taking them for granted. But seeing whether that experience down the track is still what they hoped for and expected at the outset And if not, why not?
There is no doubt that there will be times as a start-up, particularly when you grow, that you start to feel you’ve lost your way in maintaining that contact. But if it’s at the heart of what you do you’ll keep pulling yourself back to what is important. Get that right and everything else follows.
James Barnes, Co-Founder StatusCake.com
Share this
6 min read The Real Cost of Owning Monitoring Isn’t Code — It’s Everything Else In Part 1, we explored how AI has dramatically reduced the cost of building monitoring tooling. That much is clear. You can scaffold uptime checks quickly, generate alert logic in minutes, and set-up dashboards faster than most teams used to schedule the kickoff
5 min read AI Has Made Building Monitoring Easy. It Hasn’t Made Owning It Any Easier. A few months ago, I spoke to an engineering manager who proudly told me they had rebuilt their monitoring stack over a long weekend. They’d used AI to scaffold synthetic checks. They’d generated alert logic with dynamic thresholds. They’d then wired everything
3 min read In the previous posts, we’ve looked at how alert noise emerges from design decisions, why notification lists fail to create accountability, and why alerts only work when they’re designed around a clear outcome. Taken together, these ideas point to a broader conclusion. That alerting is not just a technical system, it’s a socio-technical one. Alerting
3 min read In the first two posts of this series, we explored how alert noise emerges from design decisions, and why notification lists fail to create accountability when responsibility is unclear. There’s a deeper issue underneath both of those problems. Many alerting systems are designed without being clear about the outcome they’re meant to produce. When teams
3 min read In the previous post, we looked at how alert noise is rarely accidental. It’s usually the result of sensible decisions layered over time, until responsibility becomes diffuse and response slows. One of the most persistent assumptions behind this pattern is simple. If enough people are notified, someone will take responsibility. After more than fourteen years
3 min read In a previous post, The Incident Checklist: Reducing Cognitive Load When It Matters Most, we explored how incidents stop being purely technical problems and become human ones. These are moments where decision-making under pressure and cognitive load matter more than perfect root cause analysis. When systems don’t support people clearly in those moments, teams compensate.
Find out everything you need to know in our new uptime monitoring whitepaper 2021