How we work··3 min read

Why we run what we build

Software is only useful when it is up. Why deployment, hosting and monitoring are part of every engagement, and what changes when one team is responsible end to end.

There is a moment at the end of most software projects where the code is handed over and the builder walks away. We have been on the receiving end of that moment, taking over systems built by someone else, and it is rarely a good one.

So we do not do it. We deploy, host, monitor and manage what we build.

Software is only useful when it is up

A booking engine that is down on a Saturday evening is not a booking engine. A member portal that breaks when a payment gateway changes its API is not a member portal.

Building the system is half the work. Keeping it running, secure and current is the other half, and it never ends. If the team that built it is not responsible for that half, someone less familiar with it will be.

What one team responsible end to end changes

Decisions get better. When you know you will be the one woken up at 2 a.m., you design for it. Better logging. Fewer moving parts. Deploys that can be rolled back.

Problems get noticed first. Monitoring means we see the error before the client's customer does. Most fixes happen before anyone outside the team knows there was something to fix.

The system keeps improving. Small changes after launch, the ones that make a system fit the business better each month, happen because there is someone whose job it is to make them.

What this means for you

Hosting, domains, deployment, monitoring and care are part of the engagement, not a separate conversation. There is one team to call, and it is the team that knows the system best.

We think that is how serious software should be built. It is certainly how we want to build it.