We build software, and stay with it

We spend time with your team, understand how the business actually works, and put over twenty years of experience to work on your specific problem.

You come away with something you can act on. Documents, designs, processes, prototypes. A clear view of what's worth building, what isn't, and what to do first.

Then development and QA, in chapters of focused work and bridges of review. The chapters are when we build. The bridges are when we test what we've built, take stock, and plan the next chapter. We call it Narrative Flow. It's what shipping software, project after project, has taught us.

We care about how our applications are made, not just what they do. Code other people can read. Patterns that hold up. Decisions we can defend in years to come. That might cost a little more up front, but a lot less over time.

Infrastructure as a service. We manage the platform, monitor what's running, deal with the things that go wrong, and stay ahead of the things that might.

We didn't build everything we run. Plenty of Run clients arrive with a system someone else wrote, sometimes with nobody left who remembers how it was put together.

So we start by finding out what's actually deployed, rather than what the documentation says is. Then we get it somewhere we can change it safely: the platform understood, the failure modes known, the monitoring telling us something useful. After that, running it is the straightforward part.

Once it's live, we look after it. At whatever level you need, from keeping the lights on through to active development on a system that's still growing.

We support best what we know inside out, so software we built ourselves is easiest to look after. But plenty of what we support started elsewhere. We learn a codebase properly before we touch it, so we can support it with the same confidence as our own.