Tools and stacks
Build, buy or wire together: choosing an automation stack
A decision path for the make-versus-buy question
Context
Every automation project meets the same fork: buy a product, wire existing tools together, or build something custom.
The wrong answer is rarely fatal on day one. It shows up a year later as licence sprawl, brittle glue or a custom system nobody can maintain.
The right answer is workflow-specific — which is why blanket rules like 'never build' and 'never buy' both fail.
What changed with AI systems
AI-assisted development has cut the cost of custom builds, moving the build-versus-buy line for smaller businesses.
Workflow platforms have matured into serious glue — but glue still inherits every limitation of the tools it connects.
Vendors now bolt AI onto everything, which makes 'the product already does that' claims worth testing rather than trusting.
How to approach this in your organisation
- 01Start from the workflow, not the tool: write down what must happen before evaluating anything.
- 02Buy where your need is genuinely standard — calendars, accounting and payments are solved problems.
- 03Wire tools together where the need is standard but the combination is yours.
- 04Build only where the workflow is your edge, and budget for its maintenance like any other asset.
- 05Whatever the mix, keep your data exportable — the stack will change again.
Key metrics
- Licence count and overlap across the current stack.
- Steps in the workflow that still require manual bridging between tools.
- Time to change the workflow when the business changes.
- Dependence: what breaks if any single vendor disappears.
Risks to consider
- Choosing the stack before understanding the workflow.
- Glue chains so long that no one can say where a failure started.
- Custom builds with a single maintainer and no documentation.
- Vendor lock-in discovered at export time.