01
Read the system
Before proposing anything we trace the data end to end and interview the people working around the gaps. Most briefs describe a symptom. The first week is spent finding what is actually causing it.
Output
Written findings
Method
How the
work runs.
Every engagement follows the same four steps. The point is not process for its own sake — it is that each step produces something you can hold us to before the next one starts.
01
The four steps
In order, no exceptions
02
Name the constraint
One thing sets your throughput. We identify it, size the cost of leaving it alone, and agree in writing what we are and are not solving. Scope disputes happen here, on paper, not in month three.
Output
Scope & fixed price
03
Build the smallest version
Working software in front of real users inside three weeks, then iterated. We do not disappear for a quarter and return with a platform. You see the thing while it is still cheap to change.
Output
Shipped increments
04
Hand it over properly
Runbooks, tests, architecture notes, and two weeks of paired work with whoever inherits it. The engagement is finished when your team ships a change to it without calling us.
Output
Handover & runbook
02
Engagement shapes
Indicative — scoped per client
A
Assessment
1–3 weeks
From $18,000
Written findings, ranked risks, priced options
Credited against a build if you proceed within 90 days.
B
Build
6–16 weeks
From $85,000
Working system, tests, runbook, paired handover
Fixed price against a fixed scope agreed in writing first.
C
Review
Ongoing, 1 day / week
$6,400 / month
Design review, PR review, on-call for decisions
Capped at six months. We are not trying to become permanent.
Figures are indicative starting points for scoping conversations, not a rate card. Scope, access, and the state of the existing system move them in both directions.
03
Working principles
The ones with teeth
01
The estimate is the commitment
Fixed price against a fixed scope. If we estimate badly, that is our problem, not a change order. The corollary is that we spend real time on scope before quoting, and we will decline work we cannot size.
02
Findings go in writing, including the bad ones
Anything we discover that materially affects cost, risk, or feasibility is written down and sent the week we find it. Nobody should learn about a problem in a final presentation.
03
Your team is in the repository from week one
Not handed a finished system at the end. If nobody internally has time to be involved, that is a real constraint and we would rather discuss it before starting than discover it at handover.
04
We use boring tools on purpose
Technology choice is weighted toward what your team can already hire for and operate. A more elegant stack you cannot staff is a liability we would be handing you on the way out.