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.

We’re a small startup (10 people at time of writing) with big ambitions, particularly when it comes to our product. With so many things we want to do, it’s important for us to be structured the way we approach our work, without being so process-driven that we lose all the benefits of being small and nimble. As we’re still new, and the team is growing all the time, very little is set in stone.

We wrote this article in response to a question asked in our Slack Community. Click here to join hundreds of technology leaders discussing best practices for incident response! ✨ We know a thing or two about incident response. As such, we're often asked to advise when companies are designing their incident response processes. A common question is "How do you design your incident severity levels?". It's a great question given how central they are to incident response!

Based on our newfound data feet, we’ve started consistently tracking the adoption rate of our latest features. As it happens, we’ve been impressed with the results! For example, we were delighted to see that our new tutorial flow was completed end-to-end by 35% of our users (against an industry average of less than a quarter for 6-step product tours like ours). I know, I know: being at such an early stage means it is arguably easier to hit customer needs on the head.

There’s no one-size-fits-all incident response process. Depending on your organisation’s shape and size, you’ll have different requirements and priorities. But the same three pillars form the core of any good process, whether it’s for the largest e-commerce giant or a scrappy SaaS startup.

The role of an engineer at a startup is a tangled web: as well as writing code, you have to be your own product manager, QA tester, customer support and designer. But there’s another hat that you have to wear which you might not have thought about: copywriter. All products have copy, from welcome messages to text on a submit button. At incident.io, we have to put on our copywriting hats every time we add a new feature.