Method and commercials
How an engagement actually runs
Three ways to engage, one method, and a set of standards that do not get relaxed because a date is close. Most of what follows exists because we have watched the alternative fail.
- Engagements
- Under NDA as standard
- People
- Background-checked engineers
- Data
- GDPR and DPA ready
- Infrastructure
- World-renowned cloud providers
Commercials
Three ways to engage
Assessment · 2 to 4 weeks
A fixed-scope, fixed-fee piece of work with a written deliverable. Due diligence, architecture review, infrastructure audit or a QA maturity assessment.
Project delivery · 2 to 6 months
We own an outcome end to end. Discovery, architecture, build, test, launch and a documented handover to your team.
Augmented team · Rolling, 3-month minimum
Named engineers embedded in your squads, on your board, in your standups, under your technical direction, with our review standards behind them.
We do not publish day rates. A rate without a scope helps nobody, and a fixed price for a scope neither side understands yet is a dispute with a signature on it. You get an indicative range on the first call and a fixed price per increment once discovery is done.
Method
Six things we do on every engagement
- Understand before proposing
- Every engagement starts by reading the code, the infrastructure and the incident history. Proposals written from a brief alone are guesses with a price on them.
- Increment, then re-forecast
- Work ships in two-week increments with a working demo and a revised forecast at the end of each. Scope changes; pretending otherwise is how projects end in dispute.
- Documentation as a deliverable
- Decision records, runbooks and specifications are written as the work happens, not assembled at the end for a handover meeting.
- Your conventions, not ours
- Inside your codebase we follow your patterns. A module written in our house style is a maintenance liability we would be handing you.
- Named people, direct access
- You talk to the engineer doing the work. There is no account management layer, and nobody is swapped out without your agreement.
- Exit without a cliff
- Every engagement ends with a handover your team can act on: documentation, a walkthrough and a support period. No dependency is created on purpose.
Standards
What does not get relaxed
Review before merge
Every change is reviewed by a second engineer, and architecture-affecting changes by a principal. No exceptions for urgency.
Tests where money moves
Money paths, idempotency and compliance gates carry automated tests before a feature is considered done.
Production access is deliberate
Least privilege, named accounts, audited access and a documented offboarding that actually revokes everything.
Observability ships with the feature
Logging, metrics and alerting are part of the work, not a follow-up ticket that never gets prioritised.
Starting
From first call to first increment
01
First call
Forty-five minutes with an engineer. You describe the problem, we tell you whether we are the right people and what it usually takes.
02
Scoping
A short written scope with a fixed price for the first increment, plus the risks we can see from outside.
03
Discovery
One to two weeks inside the code and the infrastructure, ending in a plan sized in engineering weeks.
04
Delivery
Two-week increments, working software at the end of each, with a re-forecast you can act on.
Next step
Tell us what you are building, or what you are about to buy.
One working day to a reply, from an engineer rather than an account manager. Under NDA as standard, before anything is shared.