Skip to content
How we work

No surprises, in either direction

Most software projects go wrong in the same few places. This is how we avoid them — and what we expect from you in return.

Commitments

Three things we hold to

Scope before spend

We agree what is being built, what it costs and when it lands before anyone commits. If we think the idea is wrong, we say so in the first conversation rather than the fourth invoice.

You talk to engineers

The people writing the code are the people in your meetings. Nothing gets relayed through an account manager and lost on the way.

We operate what we build

Shipping is not the finish line. We stay responsible for uptime, maintenance and the boring parts — or we hand over documentation good enough that you do not need us.

Process

What actually happens

  1. 01

    Conversation

    You tell us what needs to exist and why. We ask the awkward questions — who uses it, what happens if it does not get built, what already exists that we should not replace. Free, usually an hour.

  2. 02

    Written scope

    We come back with what we would build, what it costs, and when it lands. It is specific enough to argue with. If we think part of it should not be built, that is in there too.

  3. 03

    Build, in the open

    Work happens in your repository or one we hand over at the end. You see progress continuously rather than at milestones, and you talk directly to whoever is writing the code.

  4. 04

    Live

    Deployed to infrastructure in your name, on your accounts. You own the domain, the hosting and the code — there is no version of this where leaving us is difficult.

  5. 05

    Running

    We either stay on to operate and maintain it, or we hand over documentation good enough for someone else to. Both are fine. Being quietly indispensable is not the business we want.

What we need from you

Projects fail on the client side too

We are honest about our part, so here is yours. None of it is demanding, but a project missing these will drift regardless of how good the engineering is.

  • One person who decidesNot a committee. Someone empowered to answer a question the same week it is asked.
  • Access, earlyAccounts, credentials and the systems we have to integrate with. The single most common cause of a slipped date is waiting on an account.
  • Real contentActual copy, real data, genuine images. Placeholder content hides problems that only surface at launch.
  • Willingness to cut scopeEverything takes longer than it looks. Deciding what to drop is better done deliberately in week two than in a panic in week nine.

Tell us what needs to exist.

Send a couple of paragraphs about the problem. We will come back with what it would take to build — scope, timeline and cost — or tell you honestly if we are not the right fit.