Know what to build, in what order, and what it will cost — before you commit.
A short engagement that turns an idea, a backlog or a vendor proposal into a scoped plan: what is in, what is out, what it depends on, what it costs, and what a first release looks like.
- Listen
- Scope and architecture
- Estimate and sequence
- Sign
Our estimates are written to be checked.
The most expensive mistakes in software are made before the first line of code: a scope nobody wrote down, a dependency nobody noticed, a vendor quote compared against nothing, a roadmap that lists everything and sequences nothing. Months in, the project is late and no one can say against what.
Scoping is engineering work and should be done by engineers who will be held to the result. We take what you have — a one-page idea, a long backlog, a proposal from a vendor — and produce a plan that a delivery team can start on: the scope with its explicit exclusions, the architecture at the level needed to estimate, the dependencies and risks, cost bands, and a first release small enough to prove the idea early.
If you build with someone else and they beat them, good. If you build with us, we are held to them.
Four questions a scope has to answer.
The answers are written, argued with your stakeholders and revised until the people who will pay and the people who will build both agree.
What, exactly
The scope as a list of capabilities with acceptance criteria, and — just as important — the list of what is out. Written with the users, not only the sponsor, because the users know the exceptions.
On what
The architecture to the level needed to estimate: systems touched, integrations, data, the build-versus-buy decisions with their reasons. Enough to spot the dependency that would otherwise have surfaced mid-project.
In what order
A sequence by dependency and by proof: what has to exist first, what proves the direction fastest, and the first release a real user can touch early. The roadmap for the rest, to the level the evidence allows.
For how much
Cost and time bands per phase with the assumptions written down, a risk register with the mitigations, and a recommendation on the engagement model — fixed price, dedicated team, or a mix.
How the work runs, day to day.
Scope with the users, estimate with the engineers, decide with the sponsor.
Three groups see three different projects. Users know the edge cases; engineers know the dependencies; sponsors know the constraints. Scoping is the work of putting the three in the same document and resolving the differences before they become change requests. The output is argued in a working session with all three, and the version that leaves the room is the one everyone signed.
- Capability list with acceptance criteria and explicit exclusions
- Estimates by the engineers who would build it, with assumptions stated
- One working session where sponsor, users and engineers sign the same plan
- 01Listen
- 02Scope
- 03Estimate
- 04Sequence
- 05Sign
From idea to a plan a team can start on
How the work runs.
Listen
Interviews with the sponsor, the users and the engineers who own the adjacent systems. The material you have — ideas, backlogs, proposals — read in full.
Scope and architecture
The capability list, the exclusions, the architecture at estimating level, the dependencies and the build-versus-buy decisions.
Estimate and sequence
Cost and time bands per phase, risks and mitigations, the first release and the roadmap. The vendor proposal, if there is one, compared line by line.
Sign
The working session; the plan revised and signed. Delivery can start — with us or with anyone.
What you keep.
- A scope document with capabilities, acceptance criteria and exclusions
- Architecture and integration map at estimating level
- A sequenced roadmap with a first release defined
- Cost and time bands with assumptions and a risk register
- A recommendation on engagement model and team shape
When this is the right call.
Choose this when you are about to commit budget to something not yet written down, when a vendor proposal needs a second opinion, or when a backlog has grown past the point where anyone can say what comes first.
Look elsewhere if the scope is already clear and signed — go straight to delivery — or if the question is organisation-wide: see digital transformation strategy.
Frequently asked questions
Services that pair with this.
About to commit to something not yet written down?
Bring the idea, the backlog or the proposal. An AI-native engineer reads it and replies in writing with a view of what scoping it would take.