Tagged scoping
5 pieces
- · 10 min read
Clear One Real Transaction Before You Build The Second Feature
For a transactional product, the shortest reliable path to one real settled transaction is worth more than a broad surface built before anything clears. Breadth first means months of work resting on assumptions about payment, settlement and counterparty behaviour that nobody has tested. The narrow path is chosen by following the money, and the scope you defer has to be named rather than quietly omitted.
- · 10 min read
What Should Never Be An Agent: Use The Benchmark Gap As Your Decision Criterion
Published benchmarks of agents on realistic computer-use tasks report completion rates in the low tens of per cent, while humans on the same tasks sit near ceiling. That gap is not a reason to avoid agents. It is the input to a decision procedure: a low success rate is fine when checking the answer is cheaper than producing it, and unacceptable when the action is irreversible or verification costs more than doing the work yourself.
- · 9 min read
You Are Buying Verdicts, Not Prototypes: Price The Decision, Not The Build
When a team buys rapid prototyping, the thing they actually need is a decision: build this or do not. The cost of a wrong keep, carrying a bad idea into a full build, exceeds the cost of the prototype by a large multiple. That makes the prototype instrumentation for a verdict rather than a deliverable in itself, and it changes how the engagement should be scoped, priced and ended.
- · 8 min read
Inventory on a Copy, Touch Nothing Live
The cheapest risk reduction available in a migration is a first gate that runs entirely against a database copy and ships no features. Because there is no operational risk, the work can be thorough, and thoroughness is the entire value. This is how to scope, price and sell a milestone whose deliverable is documentation rather than software.
- · 9 min read
Two Paths Through the First Gate
When nobody knows whether a critical fact is true, shape the engagement so that both answers lead to a working product. One monitoring project did not know whether a controller could be read at all, so it was structured to decode the controller directly if yes and to instrument the surrounding physical signals if no. Neither answer stranded the capital.