The method
Big software projects fail small businesses. So we don't build them that way.
Here's exactly how we'd work with you — from the first free conversation to a system that quietly keeps getting better while you get on with the business.
Why the usual way breaks
The big build asks you to know the answer on day one.
A traditional software project asks you to specify everything up front — at the exact moment you know least about what you need. The price is fixed, the spec is frozen, and every change after signing becomes a "variation". Eighteen months later you get precisely what you asked for, which is no longer what you need. Nobody did anything wrong. The model is wrong.
The planning wedge
Deep enough for clarity. Light enough to start.
Most of what goes wrong happens in the planning: a big build spends months writing a specification, then holds you to it. We plan the other way round — deep enough to be certain of the first thing worth building, and no deeper, because the rest is better decided once you can see something real. Clarity where it counts; no time or money burned mapping a future that will change anyway.
The waste is in the specifying. A frozen spec is expensive to write and expensive to change. We do just enough of it to start well.
The engagement
What working together actually looks like.
Four steps — and the first two cost you nothing or next to nothing, so you know exactly what you're getting before you commit to anything.
-
Understand the pain
You walk us through the process that hurts most. We ask the questions that surface where the time really goes.
Free · 30 min -
Map how it works now
We draw your process exactly as it runs today — every hand-off, every re-key, every "then someone remembers to…".
The as-is map -
Find the wins together
You know where it hurts; we know what's now possible. We mark the friction worth removing first — and the parts to leave alone.
Together -
Agree module one
One clear, small first build. You know what it does, roughly when it lands, and what it costs — before we write a line of code.
Your call
The free audit is step one. The paid Discovery Sprint — £1,500, one week, credited to month one — is steps two to four done in depth, for when you want the full map before you decide.
How we build
Module one is the first brick, not the cathedral.
A module is the smallest piece of working software that removes real pain — small enough to be live in weeks, useful enough to matter on its own. Module one is deliberately not the grand vision; it's the first brick.
A wall built brick by brick is useful — and standing — at every stage, and it's cheap to change what you build next. A single prefab, lowered in one piece, only has to be slightly wrong to fit nothing.
Why it lands right
You see the real thing, early — not a spec you have to imagine.
We build the part you can actually look at first: the screen, the report, the button you'll press. From the start you're reacting to working software, not a document — so we find out we've got something slightly wrong while it's still cheap to change, instead of at the end. Most projects hide the work until it's too late. We do the opposite, and it's the single biggest reason our builds land right.
It's a principle I've built to for over a decade — I called it building visual-first long before AI made it easy.
Modern AI-assisted development is what makes doing it every cycle affordable: putting the visible result in front of you used to be the slow, expensive part. And it's the same discipline we build into your processes — AI kept where its work is checkable, logged, and set up to prove its own accuracy. Never AI you take on faith.
The rhythm
Then it compounds — the monthly build cycle.
Once module one is live, the rhythm begins. Every month we review what shipped, measure what it saved, pick the next friction, and build the next thing. The roadmap is a living conversation, not a contract appendix — and because you've been using the last module, you already know what the next one should be.
A cost you can see is not a saving until it's captured — so we measure each module before we move on. Some ideas pay off less than expected; the cycle is how we find that out cheaply.
The payoff
Small gains compound.
Each automated process frees the hours that let you notice the next one. A realistic first year looks like this — and none of it needed a two-year project to get there.
No lock-in, ever
You own everything. From day one.
Code in your repository. Data in your database. Infrastructure in your accounts. Documentation written as we go. If we ever part ways, your software keeps running — and any competent developer can pick it up. Leaving is always easy, which is exactly why staying is a choice and not a trap.
Where we'll say no
What we don't do.
- No big-bang rewrites. The business never stops while we build.
- No rebuilding what already works. If off-the-shelf software genuinely fits, we'll tell you to buy it — and wire it in.
- No lock-in. Your code, data and infrastructure are yours from day one.
And then we stay
The building can stop. The looking-after doesn't.
When you've got what you need, the build cycle can slow right down — but someone still has to keep it running. That's us: hosting watched, updates applied, security kept current, and changes made whenever you ask. It's the quietest tier of the retainer, and for a lot of businesses it's where things settle once the heavy lifting is done.
The standards we build to from day one are the standards we hold it to for as long as it's yours:
The first step is small
Start with the free bit.
Bring us the process that wastes the most time in a normal week. Thirty minutes, and you leave with a written map of what could run itself — whether or not we ever work together.
No pitch deck. No obligation. Worst case: you get a free plan.