How we work
Outsourced development usually fails in one specific way: the client finds out late. Everything below exists to make that structurally difficult, and to make leaving us easy if it happens anyway.
The shape of a project
Each stage ends with an artefact in your hands, so leaving after any one of them costs you nothing.
Week one
A short paid discovery: we map the workflow with the people who do it, agree what version one must do, and hand back a fixed scope, price and date. If you take that document to another team instead, it still works.
You keep01 / 04
The plan.
Every week after
Every week ends with a deployment you can open, a written update on what moved, and the plan for the next one. Priorities can change on Monday; they should not be a surprise in month three.
You keep02 / 04
The product.
At launch
We instrument the thing we built — how often it is used, where it fails, how long the job now takes — so the question ‘did this help?’ has an answer that is not a feeling.
You keep03 / 04
The numbers.
Afterwards
Your repository, your cloud accounts, your data, from the first commit. We can stay on for maintenance and on-call, or write the handover documentation and step back. Both are normal endings.
You keep04 / 04
The keys.
Engagement models
Pick the smallest one that answers your question. Most engagements start with a discovery week and stop there if the answer is no.
Fixed price, one week
Find out what is worth building before committing to the build.
What stays with youThe document is yours. Taking it to a different team is a legitimate outcome.
Weekly slices, billed by the week or by milestone
A small team, delivering something you can use every week.
What stays with youDeployments and updates every week, in your repository and your cloud accounts.
Monthly, capped hours
Keep the software healthy after it goes into everyday use.
What stays with youA runbook good enough that your own developer could take over.
We quote in your currency, against a written scope, and we will tell you when a fixed price is the wrong instrument for the work. Rates depend on the mix of people a project needs, so they are quoted per engagement rather than published as a single number that would be wrong for most of them.
Communication
Two lists, because a project only runs well when both sides know what they owe the other.
Standards
Commitments about how we work, not claims about results we have not measured. Each one names the thing you can check.
Ranges, not single numbers, and the list of things that would move them. When an assumption breaks we tell you the same week, not at the deadline.
The evidenceAsk for the assumption list. Every estimate has one.
Page weight, load time and interaction targets are agreed up front and checked in CI, so performance is not a cleanup task at the end.
The evidenceRun Lighthouse on anything we shipped, including this site.
Keyboard paths, focus states, contrast and reduced-motion behaviour are part of the build, not an audit we run once at the end.
The evidenceUnplug your mouse and try to finish the job.
Repositories, infrastructure and domains are in your name from day one. No proprietary runtime you have to keep paying us for.
The evidenceRead the contract. The handover clause is in it from the start.
Limits
The smallest useful commitment. At the end you have a scope, a price and a date — and no obligation to spend either with us.