What we do
Services we offer
Each one is bought in one of three shapes, and every section below says which it usually starts in.
Websites and web apps
Design through build — the interface, the thing behind it, and the path to production.
Most of this work is an application with a public face, not a page with a form on it. The interface and the system behind it are designed together, because a screen that cannot be built the way it was drawn is a decision deferred rather than made.
Mobile apps
Native or cross-platform, taken through review and into the stores rather than left at a build.
The build is the easy half. What takes the time is everything after it — signing, review, staged rollout, and the fact that a bad release cannot be rolled back the way a website can. That constraint shapes the plan from the first week rather than arriving in the last one.
Integrations and automation
Joining systems that were never meant to talk, so a person stops being the integration.
The interesting part of an integration is never the happy path. It is what happens when the other end times out, returns the same record twice, or changes a field without telling anyone — and whether the system notices before your customers do.
Forward-deployed engineering
Embedding with your team to configure, implement and build in place. The longest of the four.
This is the one that asks for real time. Being useful inside somebody else’s system means learning it first, which is weeks rather than days — so it is bought as standing capacity, and it only makes sense when the work is continuous enough to justify the learning.
If what you need is one bounded thing built, this is the expensive way to buy it. A fixed-scope project is cheaper and finishes sooner, and we will say so.
Questions
Before you get in touch.
What does an engagement cost?
There is no price list on this site, and that is deliberate. A number without a scope attached to it is a guess, and a guess that turns out low gets recovered later — through change requests, through corners, or through the engagement quietly going bad.
So the sequence runs the other way round. Discovery is a fixed fee against a fixed scope, agreed before it starts. A project is quoted once there is something specific enough to quote against. A retainer is a monthly block of capacity.
The intake form asks for a budget range. It is not a bid and nothing is priced against it — it is there so we can tell you quickly whether we are in the same conversation, which is a kindness to both of us.
Do we have to start with discovery?
Not always. If you already have a written specification that someone competent produced, and we can read the code it applies to, a fixed-scope project can start directly.
What we will not do is put a fixed price on a scope we have not read. Anyone can — the padding simply goes into the number, and you pay for the risk either way. Discovery is the cheaper version of the same protection, and it ends in a document you own outright whether or not you carry on with us.
What happens when the scope changes?
It changes. That is normal, and pretending otherwise is how fixed-price work turns adversarial halfway through.
A change is treated as its own small scope: what it is, what it costs, and what it pushes back. You approve it before it is built. When something is genuinely smaller than the cost of writing it up, we absorb it and say so rather than billing for the paperwork.
What makes that workable is that every engagement starts with the exclusions written down — which is why each model above lists what it does not include with the same weight as what it does.
Can you work inside an existing team and codebase?
That is most of the work. The usual shape is a team that is not short of ability but is short of time, with something specific that keeps slipping — an integration, a migration, a feature nobody has had a clear run at.
We work in your repository, to your review process, on your branch conventions. If a decision would outlive the engagement it goes in writing where your team can find it later, because a contractor who leaves behind code nobody can maintain has moved the problem rather than solved it.
Who owns the code and the documents at the end?
You do, outright — including the written assessment a discovery engagement produces. If you take that document to your own team or to another contractor, that is a legitimate outcome and we have no claim on it.
Writing the plan does not entitle us to the work that follows from it. An assessment that only makes sense if we win the next engagement is not advice, it is a sales call.
If what you need is a single-page brochure site, a template will serve you better than we will — and we’ll tell you which one.
If you’re not sure which of the four fits, say so in the form. Working that out is the first thing we’d do anyway.
Start a conversation