Approach
Predictability is the product.
We are not asking to be trusted — we are showing the mechanism that makes trust unnecessary. This is the page most firms in our category do not have.
01
Understand
We map the system as it is, the constraints around it, and what success actually has to look like. Nothing is estimated before this is done.
You receive
A written problem statement and a costed options paper
We need from you
Access to the people who know how it works today, and an honest account of previous attempts
02
Design
Architecture, interfaces and delivery plan, agreed before code. Trade-offs are written down, not assumed.
You receive
An architecture document, a milestone plan and a fixed scope
We need from you
One decision-maker who can sign off, and a response within three working days
03
Build
Iterative delivery against the plan. Working software every sprint, in an environment you can see.
You receive
Working software, a test suite, a running environment and release notes
We need from you
A named product owner, and attendance at the weekly review
04
Run
Production support, monitoring and iteration. We stay on for the part most vendors leave.
You receive
Runbooks, dashboards, an on-call rota and an agreed response commitment
We need from you
Agreement on what constitutes an incident, and who we escalate to
How we communicate
No surprises, by design.
Cadence
Weekly delivery review, daily written stand-up, and a monthly summary for people who are not in the detail.
Who you talk to
A named technical lead who is building the thing — not an account manager relaying messages.
Reporting
Progress against milestones, risks with owners, and decisions needed from you. One page.
Response expectations
A first reply on the shared channel within a couple of minutes, and a decision or a fix plan inside four hours during working hours, and a defined escalation path outside them.
How we assure quality
Checkable, not asserted.
Code review
Every change reviewed before merge, by someone who did not write it. No exceptions for urgency.
Test strategy
Functional, performance and device testing on every build, with the regression suite automated so the same checks run on each commit. Security, accessibility — against WCAG, ADA and Section 508 — and exploratory passes sit on top of that, and manual testing stays where judgement beats repetition. Coverage means the share of application code the automated suite exercises on each commit, measured by the pipeline rather than estimated. We hold new code to 80% line coverage and do not merge below it, and we track branch coverage on every path that moves money or personal data.
Environments
Three: development, staging and production, defined the same way on whichever cloud you run, so the environment is not the variable when something behaves differently in one of them. Staging runs the same infrastructure definitions, service versions and configuration as production, at a smaller instance size and with anonymised data. It deliberately does not share production secrets, payment providers run in test mode, and outbound email goes to a sink rather than to real customers.
Definition of done
You sign off the design before any code is written, and nothing after that is finished until it has passed the tests above and then your own acceptance testing. Defects found there are fixed before release, not carried past it.
Documentation and handover
You own everything we build.
Architecture documentation
Kept current as part of delivery, not written in the final week.
Runbooks
What to do at 3am, written for someone who was not on the project.
Decision records
Why each significant choice was made, so the next team is not guessing.
IP ownership
Everything we build for you is yours: source, infrastructure definitions, documentation, from the first commit. The repositories and cloud accounts sit in your organisation, we work in them as contributors, and the contract says so in plain words. The only things we keep are the open-source tools and internal templates we brought in, and those stay open-source.
When things go wrong
The section nobody publishes.
Estimates are wrong sometimes. Dependencies fail. Releases break production. What matters is what happens next, and whether it was agreed beforehand.
An estimate turns out to be wrong
On fixed-scope work the price and the milestones are set at sign-off and do not move afterwards: if the build turns out larger than we estimated, that is ours to carry. Genuinely new scope is priced as a change and signed off at a sprint boundary before we build it, rather than absorbed quietly into the plan. We tell you the week we know. The trigger is any milestone forecast to slip by more than five working days, and it is raised at the next weekly review or sooner, never at the deadline.
A release breaks production
Releases go out through an automated pipeline built for phased rollout and rollback, so reversing one is a routine operation rather than an emergency, and monitoring runs from the first day in production. The technical lead on your project is paged first, and a second engineer on the rota is paged if there is no acknowledgement within five minutes. The first ten minutes go on one question, roll back or fix forward, and rollback is the default unless the fix is already known and tested. You hear from us within thirty minutes of the alert, with what happened, what we did and what comes next.
A dependency or third party fails
Every external service sits behind an interface we own, so a failure is contained to one module rather than spread through the system. Where the service is critical, a fallback is agreed in the Design phase: a queue that holds work until it recovers, a cached last-known state, or a second provider. If a dependency stays down long enough to affect a milestone, we treat it as an estimate that turned out to be wrong, and the same rules above apply.
The relationship is not working
Either side can end a dedicated-team or support engagement with four weeks' written notice, and fixed-scope work at any milestone boundary, paying only for milestones already delivered. You leave with the repositories, the infrastructure definitions, the documentation and the runbooks, all of which you already hold, plus a written handover of anything in flight. We do not hold access, domains or credentials back; they were yours throughout.
Commercials
How estimates and billing work.
Project delivery
Fixed scope agreed after the Understand phase, billed against milestones.
Typically $40,000 to $250,000 per project, driven by the number of integrations, the size of the delivery team and how much of the existing system has to be understood first.
Dedicated team
Named engineers, billed monthly, with a three-month minimum and four weeks' notice.
$9,000 to $14,000 per engineer per month, driven by seniority, the delivery region and whether the role is full-time or shared.
Technical advisory
Time-boxed reviews, due diligence or fractional leadership.
$1,500 to $2,500 per day, or a fractional retainer from $6,000 per month, driven by the seniority of the person and the days committed.
Support & run
Retained, scoped to an agreed response commitment.
$2,500 to $12,000 per month, driven by the response commitment you choose, the hours it covers and the size of the estate we monitor.
Tell us what you are building.
A 30-minute call with an engineer who will work on it.A 30-minute call with an engineer who will work on it. No sales sequence, no obligation.
Book a consultationor email us directly