We’re building incident.io as the single place you turn to when things go wrong. When an issue is disrupting your business-as-usual, the last thing you want is to start opening ten different tools to diagnose and fix it! As your central incident hub, we need to give you two powers: Workflows cover the former. Workflows are like a mini incident.io Zapier.
At incident.io, we pride ourselves on providing a great product to our customers. We’re also a small team, so we move fast and (whisper it not) occasionally break things. To mitigate the impact on our customers, we have our app set up so that every time our application raises an error (via Sentry), we get paged.
Here at incident.io, we provide a Slack-based incident response tool. The product is powered by a monolithic Go backend service, serving an API that powers Slack interactions, serves an API for our web dashboard, and runs background jobs that help run our customers incidents. Incidents are high-stakes, and we want to know when something has gone wrong. One of the tools we use is Sentry, which is where our Go backend send its errors.
When building an incident response process, it’s easy to get overwhelmed by all the moving parts. Less is more: focus first on building solid foundations that you can develop over time. Here are three things we think form a key part of a strong process. I’d recommend taking these one at a time, introducing incident response throughout your organisation. Just being honest: we’re a startup selling incident management software.
As an early stage company, one of our biggest priorities is hiring. In fact, we have two company goals this year and one of them is.
For the vast majority of organisations, it’s necessary to have some form of round the clock cover to support the business. Whilst it’s most commonly a concern for engineering, it’s increasingly common to have folks from various disciplines available out-of-hours. Irrespective of role, compensating people fairly is an important factor of running a healthy and effective on-call system.
I joined incident.io recently to lead Sales, after having set up my own company. In both startups, one of the first questions I’ve landed on was: “What sales tools should we use as we scale?”. In this post, I’ll walk through our sales stack, and by extension, what I think most B2B SaaS startups can get away using when they have less than ~100 employees.
We’ve been pretty lucky at incident.io to be able to avoid dealing with more complex authentication issues for quite a while, because we piggy-back on Slack to know who you are and which organisation you work in. Whole companies have been built around doing authentication and user profiles really well, so it was pretty neat to be able to avoid doing most of that work for so long!
Getting your pricing right is critical to the success of any SaaS company, but finding a model that works can be tough. Price too high, you won’t close enough deals - your business will fail. Price too low, your business model will be unsustainable - your business will fail. To add to the complication, when you’re a new startup your goals are evolving.
