My reflections on 2023, now my second full year at incident.io. Doubled the team this year (34 to 77), launched Status Pages and Catalog, and spent the last six months building a really exciting new product.

Whenever a system has access to a consistent store, you can extend that consistency through compare-and-swap to the system's users. This post shows how you can add CAS to an HTTP API using example code and real-world examples.

If you build a state machine on top of a relational database you can abstract concurrency problems away from your business logic and allow developers to write safe-by-default code without dealing with concurrency concerns.

This post explains how to build a library that offers those protections, and how they work under-the-hood.

From the moment you learn programming people tell you "don't repeat yourself!"

So what I'm about to suggest might sound odd. But I'm here to say that if you want to ship high-quality software at pace, you should be investing in abstractions that are designed to enable copy-and-paste.

For the last three months we've been building out the incident.io catalog. This project always made me nervious – it would've been easy to build something pretty but useless – but it's ended up game-changingly good.

This post talks about some of the decisions that got us there.

From the evergreen AWS status page to hardcoded 100% uptime, no one fully trusts a status page anymore.

But why is this? Companies often start with good intentions, aiming for full transparency. So why do so many change along the way: what pressures people into an evergreen status page with poorly-reflective uptime numbers?

ULIDs are an alternative to UUIDs that solve several problems, but it's not all plain sailing.

This post shares experience using ULIDs in production, exploring some of the drawbacks in an aim to help others pick an ID format.

This was my first full year at incident.io. So much has happened - 4x'ing the team, our Series A, building loads of product – that it feels much longer.

I'll break this down into reflections on team, product and writing. Only a few aspects of my last year, but themes I like to keep track of.

Most software is simple: you have a codebase, and existing patterns for testing at a unit and integration level. But sometimes you'll face problems that aren't just adding code to an existing project, and don't have an existing test suite to jump into.

This posts shares some problems that required out-of-box thinking to find testing strategies, and gives advice on how you could use those techniques in your code.

Two part series about how we built incident.io workflows.

Part one explains core concepts used across the feature, and look at how code structure makes development easy. Followed by a deep-dive into the Workflow Builder (the configuration UI) showing how the concepts are exposed in APIs, and used to power the frontend.

Part two describes the workflow executor, showing how it listens for workflow triggers and if the conditions match, executes them. Finally, we reflect on whether we succeeded in our efforts to "slow down, to speed up!" in an evaluation of the project.