Skip to content

Approach

Predictable delivery is an engineering problem too.

Most software projects fail on communication and scope long before they fail on code. So we run the same four stages every time, with the same artefacts coming out of each one.

Stages

How an engagement runs.

  1. 01

    Scope

    We start with constraints rather than features: what has to be true, what already exists, and what breaks if it goes down. You get a written plan, a technical approach, and a way to start: a fixed price for the first milestone, or a set number of hours a week run in four-week cycles.

    • Technical plan
    • Milestone breakdown
    • Fixed quote or weekly hours

  2. 02

    Build

    Short cycles against a running environment. The work is deployed somewhere you can open from the first week, so review happens continuously instead of arriving as a surprise at the end.

    • Preview environment
    • Weekly demo
    • Open issue tracker

  3. 03

    Ship

    Launch is a checklist, not an event: migrations rehearsed, backups verified, monitoring wired up, rollback tested. We put the system into production and watch it settle.

    • Release checklist
    • Monitoring and alerts
    • Rollback plan

  4. 04

    Operate

    We stay on for as long as you need us: a support retainer, ongoing feature work, or a clean handover with documentation your own team can act on.

    • Support agreement
    • Operating instructions
    • Handover documentation

Principles

What we hold to when the pressure is on.

These are the calls we make repeatedly, so it is fair to state them up front.

Own the whole path
The same people who write the schema configure the server. Nothing gets thrown over a wall, and no problem is somebody else's layer.
Boring where it counts
PostgreSQL, containers, and plain HTTP carry the load. We spend novelty on the parts of the product that are genuinely new, not on the foundations.
Write it down
Decisions, trade-offs and operational steps get documented as they happen. The value of a system is capped by how well the next person understands it.
Leave it maintainable
Types, tests and readable code are how we keep our own velocity. They are also what you keep if you ever take the work in-house.

Working agreement

The practical terms, stated plainly.

You know which model you are buying

Most engagements are custom builds: mainstream tooling, a plain repository, handover terms agreed before we start. Some work sits on top of our own internal frameworks, and where we already have something that fits, you use ours rather than pay to have it built again. Which one applies is settled at scoping, never left to assumption.

One thread, not five

A single shared channel for day-to-day work and a written summary each week covering what shipped, what is next, and anything that changed.

Estimates are ranges

We quote a range with the assumptions written down, and we revise it in the open when the assumptions turn out to be wrong. Surprises get raised early, not at invoicing.

Security is not a phase

Secrets stay out of the repository, access is least-privilege, dependencies get updated on a schedule, and anything handling personal data is designed for that from the start.

We tell you where AI tooling is used

We build with AI coding tools, configured not to train on client work. It buys speed on the mechanical parts; it does not lower the bar. Every change is read, understood and owned by the engineer whose name is on the commit, and reviews, types and tests are exactly what they were before. If your organisation has constraints on this, raise them at scoping and we will work inside them.

Start a project