How we work

One contact, one accountable lead

Every project has a named contact who handles the conversation: your brief, the proposal, the questions, the status updates and the invoices. And it has an engineering lead who is accountable for the architecture, the code, the hosting and the handover. You always know who to write to, and nothing gets lost between departments.

When a project needs more hands, we bring in people we have worked with before, under our responsibility, and we tell you.

Everything in writing

Calls are fine for understanding each other. Decisions live in writing: the scope, the changes to it, the dates, the access you gave us. This protects you as much as us. Six months later nobody has to remember what was said on a Tuesday.

One deliverable at a time

Every engagement is cut into pieces that are each useful on their own. A piece has a name, a description of done, a price and a date. We finish one before starting the next. If priorities change between pieces, the plan changes with them, without renegotiating what was already built.

Test first, then live

From the first week there is a test address where every change lands. You click through it, you tell us what is wrong, we fix it, and only then does it go live. Production is never the first place you see something.

You can see the work

The repository is yours and you are in it from day one. Commit messages are written for a human. The README explains how to run and deploy the thing. If you have an engineer, they can follow along; if you do not, you can still see that work is happening.

When we say no

We say no to building before the scope is signed and the deposit is paid. We say no to secrets in chat messages. We say no to shipping something we know is insecure because the date is close. We say no to "just one more small thing" without writing it down. These are not rules for their own sake; each one exists because the opposite went badly once.