Last Christmas, after everyone had gone quiet for the holidays, I sat down with a pen and some paper and started drawing Spike. Not the Spike we actually had, but the Spike I wanted, the one I had been carrying around in my head for a long time without ever really putting it down anywhere.
A little while later I brought a few of those screens into Figma and showed them to the team over coffee one afternoon. I half expected them to just be nice about it, the way people usually are when a founder shows them something they’ve clearly been up too late working on, but they were not just being nice. They really liked where it was going, and hearing that just started to feel real to me.
Why now
The honest truth is that we had known for a long time that our old design was not going to scale, and we had been quietly living with that knowledge for longer than I would like to admit.
We have always been a backend-first team, and for years we put almost all of our energy into the part of incident response that actually matters when things are on fire, which is the reliability, the escalation logic, the work of getting the right person paged at three in the morning when it really counts. The frontend carried a lot of debt while we did all of that, and honestly that was a deliberate choice and the right one at the time. But debt has a way of compounding while you are not looking, and at some point our old stack, all that jQuery and Handlebars and Bootstrap that we had bent into shapes it was never really meant to hold, just stopped being something we could keep building on.
For the longest time I kept telling myself there would be a better moment to deal with it. A quieter quarter, maybe, or a slightly bigger team. I don’t believe that anymore. There is no such thing as endless design, and there is certainly no perfect time to go and do the hard thing. Time does not stop and wait for you to catch up, it just keeps moving whether you are ready or not, and eventually you have to accept that and sit down and actually do the thing you have been putting off.
So that’s exactly what we did.
How we built it
Before we committed to anything big, we tried the honest way first. Nikhil built us a single dropdown, but he built it properly, in our existing stack, fully keyboard-friendly and extensible and looking like it actually belonged on the modern web. By the time he had it working it had eaten an enormous amount of his time, and even then it still did not quite feel right. That one little dropdown ended up teaching us everything we needed to know, which was that the problem was never going to be any single component we could fix on its own. The problem was the whole foundation sitting underneath all of them.
Daman had been quietly campaigning for React for a while by then, and I’ll be honest with you, he was not going to back down on that one no matter what I said. He turned out to be completely right. So we flew the whole team down to Bangalore and spent four days working together in the same room, face to face, which we genuinely had not done in far too long.
We started by writing down every single complaint we had ever heard. Every bit of feedback, every rough edge, every “why on earth is this so hard” that any customer had ever sent our way, and we put all of it up on one big wall where we could finally look at it together. And once it was all sitting in front of us like that, something clicked for the whole team at the same time. These were not a hundred separate bugs that each needed their own separate patch. They were really just the same handful of problems showing up over and over again in slightly different clothes, and with React and shadcn working together we could finally knock all of them down at once instead of one painful fix at a time. Claude Code made the whole thing move at a pace that still feels a little absurd to me when I think back on it. Work that would honestly have taken a backend-first team like ours something close to six months got done in a matter of days.
Over those few days we got the integrations page built, the themes page built, and we even started playing around with Command+K just to get a feel for what Spike could one day become. By the time we went out for dinner we were completely flying on it. Daman, for whatever it is worth, ordered the pork chops in some Thai sauce and absolutely hated every single bite of it, so not every experiment that week was a success.
We came home and just kept going from there. The one rule that held all of it together was that every single day, on our calls, we would demo whatever we had built. If you made something, you showed it, simple as that. It was not until about two weeks ago that we finally put everything up on a staging server, and that’s when I started quietly putting it in front of customers, one person at a time, to hear what they actually thought.
What we actually learned
This next part is the one I genuinely did not see coming.
We walked into this whole thing assuming it was a UI project, just new components and cleaner screens and a fresh coat of paint on top. We walked out of it having learned far more about user experience than we ever did about user interface. The interface is really only the part you can see. The experience is the deeper thing underneath, it is whether the software actually got out of your way and let you do what you came in to do, and almost every good decision we ended up making came from chasing that second thing instead of the first.
Linear and Superhuman are what taught us to think that way, if I am being honest about where it all came from. I have used both of them every single day for the last three years and I’ve never once felt the pull to go back to anything else, and that is the bar we are holding ourselves to now.
The incident page
If you want to really see what we mean by all of this, the incident page is the place to look.
The old version of it was, frankly, just boxes, boxes sitting inside other boxes, and your eye never quite knew where it was supposed to land first. The new one puts the payload right up front where it belongs, because the payload is the thing you actually came to read in the first place. All of your actions now live together on the right-hand side instead of being scattered all over the screen, and we have taken the activity log and the notes and merged them into one single timeline that you can just read straight down.
We also decided to drop comments entirely. From now on you simply tag each other inside notes, so there is one clear place to have a conversation about an incident instead of two places that were always quietly competing with each other. And whenever you are ready to close something out, you can add a proper resolution note as you go.
One of the things I’m happiest about is that we taught Spike to ask you the right question at exactly the right moment. If you drop a note and mark it as resolved, Spike will quietly check whether you would like to resolve the actual incident too. And if you try to escalate an incident that somebody has already acknowledged, Spike will gently stop you and ask whether you want to unacknowledge it first and then escalate, or just cancel altogether, because the truth is that somebody acknowledged that incident for a reason and we really should not just steamroll straight over that. They are small moments, but small moments are usually the whole difference between software that you trust versus software that you fight.
There is also a new connection to Statuspage that I am genuinely excited about. You can now open a Statuspage incident directly from inside Spike, and when you resolve the incident on our side, we will go ahead and try to resolve the matching Statuspage incident right along with it.
Everything else that changed
Pretty much everything else we did came from the same three instincts we kept coming back to over and over, which were to make it fast, to make it keyboard-first, and to make it simple.
On the speed side of things, we rebuilt filters into something you’ll actually enjoy reaching for, and now when you hover over any incident a little set of ghost buttons quietly appears, so you can set severity and priority in a single click without ever opening anything up. We have also pulled time-to-resolve right out onto the incident table itself, and you will see it sitting there no matter which plan you happen to be on.
On the keyboard side, you can now move around using the arrow keys just about everywhere you go. Pressing N creates a new anything, pressing C creates a new incident specifically, and D lets you declare on a status page. And Command+K lets you move through the whole of Spike without ever really needing to lift your hands off the keyboard.
On the simplicity side, escalations finally got a proper structure for those of you running more than one policy, which honestly used to be genuinely confusing to navigate, and we added live edit on top of that, so you can change a policy and have it autosave instantly, and then just undo it if you did not mean to. On-call now leads with the calendar instead of burying it under a great pile of configuration, and you can drag right across it to add an override, which I have come to enjoy far more than I ever expected to. And with status pages we honestly just stripped them right back, because when we actually went and looked at the data, almost nobody was using all the deep customization we had built. Simplicity has always been in our DNA, so this time we leaned all the way into it.
The mobile app went the other way
There is one decision we made that runs in the complete opposite direction to everything else here, and it’s the one I’m proudest of. On the web we leaned into React. On mobile, we did the exact opposite, ripped React Native out entirely, and rebuilt the apps as fully native instead.
The thing that pushed us there was alerts. On Android we simply could not get past the limitations around making an alert reliably break through and actually make a sound when it needed to, which for an incident response tool is not a small detail, it is the entire point. If Spike cannot wake you up at three in the morning, none of the rest of it matters. The deeper we dug, the clearer it became that React Native was never going to give us the access to the native APIs we needed for that part to work the way it has to.
So I insisted we go native. We did a lot of research before committing to it, and almost all of it pointed the same way, that native apps simply feel more native, more smooth, more like they belong on the phone in your hand. For something you reach for in the middle of a stressful incident, that feel is not a nice-to-have at all. So that’s the route we took.
What’s next
This is the part I’m most excited about, and the funny thing is that we are really only at the very start of it.
What we have done here is not just a rebuild of the old Spike, it’s the foundation for everything we want to do next. The interface is finally ready to grow into things like automatic post-mortems, a much deeper activity log, and real-time updates running all the way through the product. This is the beginning of Spike’s AI chapter, and the only reason that chapter is even possible is that we now have a clean, fast, modern base to build the whole thing on top of.
I genuinely feel like this is a new era for us, and I do not mean that as a tagline or some marketing line. I mean it as the actual, honest truth of where we are right now.
To everyone who built this alongside me, and to every single one of you who took the time to tell us what was broken and then waited patiently while we went off and fixed it, thank you, really. Please keep telling us. Send us everything you have got, because that feedback is the thing that makes the next version of Spike better than this one.
And thank you for being a Spike user.
Kaushik