Most pieces of work do not need a dedicated build.
They need outcomes that a one-off script, a spreadsheet, or an off-the-shelf tool cannot reliably deliver.
Here’s the practical test I use.
The three signals
1) The outcome is hard to bolt on
If a competitor could buy the same capability or the same dataset next week, you don’t have a build — you have a configuration. A dedicated build matters when the outcome depends on knowledge and assets accumulated through operation, research, dealflow, fieldwork, or institutional learning.
2) The outcomes are high-leverage
The best use cases are not “automate the small stuff”. They’re outcomes that move money, risk, or time:
- “Which assets are mispriced given these constraints?”
- “Which compliance pathways are viable for this product variation?”
- “Which properties match this thesis across jurisdictions and planning constraints?”
3) The current workflow is slow and fragile
If the answers require analysts stitching together sources, or senior experts doing mental joins, you have a bottleneck.
A dedicated build turns bottlenecks into interfaces — so the organisation can get reliable answers more frequently, without the same manual effort.
What to build first
Not a prototype. A system:
- architecture that respects the real constraints
- tests and evaluation so delivery is verifiable
- interfaces aligned to the real workflow
- ownership you can maintain without the original builder