The cheapest way to find out what you are actually holding
Project Scoping
Software projects rarely fail at the build. They fail at the point where nobody could say what done meant, and everyone estimated anyway. This is the small, priced step that removes that ambiguity before the expensive commitments start.
What a scoping engagement produces
The four deliverables, walked through by the architects who write them.
90 secSample frame · video pending01Three doors, one discipline
Name what you are holding.
An unsized project, a pile of AI-generated code and an inherited system look like different problems. They are the same problem wearing different clothes: something exists, or is about to, and nobody can honestly describe it yet.
What are you holding that you cannot yet size?Three situations bring people to this door. Pick yours and the assessment changes shape.
Project scoping engagement
The disagreement is not about effort. It is about scope, and no estimate converges until the boundary, the acceptance conditions and the integrations are written down.
A scope boundary document within the first week: users, workflows, exclusions and what acceptance actually means, written so your team can argue with it.
- Scope boundaryWhat is in, what is out, and what does done mean?Written exclusions and acceptance conditions your team signs before anyone estimates.
- Architecture and integrationsWhat must it connect to, and what will that cost?Integration contracts, structural risks and the decisions that get expensive to reverse.
- Delivery sequenceWhat order removes the most risk earliest?A milestone plan with dependencies, evidence points and honest unknowns.
- Commercial basisWhat can be committed to responsibly, and at what price?Assumptions, a delivery boundary and a number suitable for a real proposal.
Not sure which of the three describes you, or holding something that fits none of them? Describe it to us instead
02Two weeks, four stages
Short enough to fund from a discretionary budget.
The engagement is deliberately small. It has to be affordable enough that finding out is easier than guessing, and short enough that it does not become the project it was meant to define.
Access and orientation
Repositories, existing documents and conversations with whoever holds the context. We read the system before offering an opinion about it.
Understanding you can correctExamination against your reality
Your traffic, your compliance duties, your team size. A generic checklist would produce generic findings, which help nobody.
Evidence, not impressionsFindings and honest paths
Findings ranked by business damage, with two or three genuine routes costed. A single inevitable recommendation usually means the answer was decided in advance.
Options, not one verdictHandover and walkthrough
Everything handed over and talked through with your team. It stays useful whether we build the thing, someone else does, or nobody does.
A pack you own
03The decision pack
Four documents, yours to keep.
The output is not a proposal with an assessment attached. It is a decision pack you own outright and can hand to any vendor, including ours, to be quoted against on equal terms.
Scope boundary
Users, workflows, constraints, explicit exclusions and what acceptance actually means, written to be argued with rather than admired.
Technical direction
Architecture decisions with their trade-offs, integration contracts, security posture and the questions still genuinely open.
Delivery sequence
Milestones, dependencies and evidence points, ordered so the riskiest unknowns resolve earliest rather than last.
Commercial basis
Stated assumptions and a delivery boundary firm enough that any competent vendor could quote against it responsibly.
04Evidence and proof
Assessments that changed the decision.
The measure of a scoping engagement is whether it changed what happened next. Nothing shown here goes live without the client's written sign-off; the previews exist to show the bar we hold.
Explore case studiesA two-week assessment that cancelled a six-figure build.
A platform team was ready to commission a custom system. The scope boundary showed a configured product covered eleven of their twelve workflows, and the twelfth was a two-week integration.
- Build budget released
- Six figures
- Assessment duration
- Two weeks
They talked us out of the build we came for. That is the single reason they got the next three projects.
Sample · pending client approval
05When to skip this entirely
Three reasons not to scope with us.
Scoping earns its fee by preventing a larger mistake. When there is no larger mistake available, it is overhead, and saying so costs us one small engagement and earns a straight reputation. Technical due diligence for an acquisition is a related but different exercise with a different buyer.
- Custom software development
The boundary is already agreed
If your team can state the exclusions and acceptance conditions without argument, you have already done this work. Go and build.
- Hire developers
You need people, not a plan
If delivery is running well and the gap is capacity, adding engineers reaches the outcome faster than another document will.
- Legacy modernisation
The system needs modernising, not assessing
When everyone already agrees the estate must change in stages, the modernisation practice starts with its own assessment built in.
06Straight answers
Asked before an assessment is funded.
01What does a scoping engagement cost?
It is fixed-price and deliberately small, sized so that finding out costs materially less than guessing wrong. The exact figure follows the system's size and the number of integrations, and it is stated before anything starts rather than discovered during.
02How do you fix AI-generated code?
By assessing it before touching it. Generated code fails differently: it is locally plausible and globally inconsistent, so the review targets duplicated logic, swallowed errors and untested branches. The output is a risk-ranked register separating what will break, what is merely ugly, and what is genuinely safe to keep.
03What is a codebase assessment or software audit?
A structured examination of an existing system: architecture, dependency health, security exposure, test coverage and the real cost of the next change. It produces a system map and a risk register rather than a verdict, so your team can decide what to act on and in what order.
04Is this the same as technical due diligence?
Related but not identical. Technical due diligence serves an acquirer deciding whether to buy a company, and weights commercial risk accordingly. This serves an owner deciding what to build or fix next. The examination overlaps; the questions being answered do not.
05Do we have to build with you afterwards?
No, and the pack is written on that assumption. It is deliberately vendor-neutral so you can put it in front of any competent supplier and receive comparable quotes. Roughly the point of the exercise is that you stop being dependent on one opinion.
06How much access do you need to our systems?
Read access to the repository and whatever documentation exists, plus time with the people who hold the context. Where access is restricted we work from what can be shared and state plainly which findings are therefore provisional.
07How long before we can start?
Usually days, because an assessment needs conversation and access rather than an assembled team. The engagement itself is two weeks in most cases, and larger estates are split into a first pass and a deeper follow-up rather than stretched.