How Our Process Is Different

Published 12 August 2026 · Rich Hickson

The diagram is not the process

Look at ten agency websites and you'll find roughly the same five boxes with roughly the same verbs. Ours are on the home page and they aren't original either. Anyone can draw boxes. The interesting question isn't what the steps are called; it's who's standing in each one.

That's where most projects are quietly decided, and it's the thing almost nobody publishes.

The handoff problem

Here is the shape of a typical agency project. A salesperson runs discovery. A business analyst turns the notes into a specification. A project manager owns the timeline. One or two developers, often junior, do the build. A support desk inherits the result.

Five people, four handoffs. Every handoff is lossy. The detail you mentioned almost as an aside in the first meeting, the one that is actually the reason you are commissioning software at all, gets compressed out somewhere between the salesperson's notepad and the developer's ticket. Nobody is negligent. It's just what happens when context is passed along a chain.

The visible symptoms are familiar: you explain the same thing three times to three people, the build comes back technically matching the spec but missing the point, and change requests turn into a negotiation because the person you're talking to can't price them.

We don't have that chain. There is one person from the first conversation to year three of support (the TrotBritain platform was built exactly this way, start to finish). Not as a scrappy startup constraint, but as the deliberate shape of the business.

What one person changes at each step

Discover. The person asking the questions is the person who will write the code. That makes the questions better, because they are asked by someone already picturing the data model, the edge cases, and what your rota looks like at 6am on a bank holiday.
Plan. The specification is written by the builder, which means the estimate is a commitment rather than a guess passed down the line. That's why we can quote a fixed price at all.
Build. No relay. When you ask "can we also do X", you get an answer that day from the person who knows what X actually costs, not a request logged for consideration.
Launch. Handover into accounts registered to you, because ownership only counts if it survives you leaving.
Grow. The person maintaining it in year three is the person who wrote it in year one. Nothing gets rediscovered from scratch, and no institutional memory walks out with a departing employee.

Why we can fix-price when most cannot

Fixed quotes are common in marketing copy and rare in contracts. The reason is structural. If the person estimating isn't the person building, the estimate has to carry a risk premium. So it gets padded, or the whole thing moves to time and materials, and the meter runs while somebody else's learning curve is billed to you.

When the estimator and the builder are the same person, that premium mostly disappears. You get a written specification and a fixed price before any build work starts, and payments are tied to delivered milestones rather than hours elapsed. If we get the estimate wrong, that's our problem to absorb. It's a genuine transfer of risk, and it's only affordable because discovery was done properly by someone who had to live with the answer.

We are our own most demanding client

Alongside client work we run our own products: CalmRota, EndorseHQ, and CalmStaff. That's not a portfolio flourish. It means we carry the consequences of our own engineering decisions in production, on real customers, indefinitely.

A shortcut taken during a build doesn't disappear at handover. It comes back as a support call on a Monday morning. That's a kind of discipline you can't really fake, and it's not available to a business whose model is to ship and move on.

The step nobody advertises: saying no

Occasionally the honest output of discovery is that you shouldn't build anything. If a £30/month tool genuinely covers what you need, we'll tell you so and lose the project, because a bespoke build that should have been a subscription is a bad outcome that both sides have to live with for years.

Bespoke earns its cost when your process is the advantage, when the off-the-shelf option covers 70% and the missing 30% is where your team loses hours every week. Discovery exists to establish which of those you are, not to justify a quote that was already written.

Four questions worth asking any developer

Who exactly runs discovery, and will that person write the code?
Is the specification produced by the person building it, or by someone else?
Is the price fixed before the build starts, and what happens if the estimate is wrong?
Who answers the phone in year three?

The answers tell you far more than the diagram does.