a small decision tool

buy, automate,
or build?

The best next step is sometimes a smaller one. Answer five questions to explore whether to buy a tool, connect what you already use, or scope a bespoke build.

This is a transparent decision aid, not a quote or a score of your business. It runs in your browser. Your answers are not submitted or saved.

start with your workflow

a sensible next step

Resolve this first:

your starting brief

Use this starting brief to investigate the recommendation and its assumptions.

how the recommendation works

The first unresolved dependency determines your next step. The rules below explain each recommendation.

If the outcome is unclear, map one real workflow and its desired result before choosing technology.
If the process is still changing, resolve that uncertainty before automating it.
If existing products have not been tested, compare them against the essential acceptance examples first.
If an existing product fits, or configuring it closes the gap, test buying or configuring it before commissioning a build. Name an owner before committing.
If ownership is missing, agree who will accept and operate the result before a bespoke or automation project.
If connecting systems is essential and interfaces are unverified or blocked, investigate access and integration feasibility first.
If you identify a handover between tools but also say no systems need to connect, clarify that mismatch before choosing an implementation.
If the gap is repeated handovers between accessible tools, test one small automation with an exception path.
Otherwise, scope a small bespoke proof of the workflow, with acceptance examples and a comparison against the closest alternative.

compare the work, not the label

Where each route can fit
Route	Useful when	Check before committing
Buy or configure	A product covers the important workflow well enough.	Real task fit, migration, access, recurring fees and exit options.
Automate a handover	Existing tools fit, but a repeated step between them wastes effort.	Supported interfaces, failure alerts, retry behaviour and an owner for exceptions.
Build bespoke	An important requirement remains after concrete alternatives have been tested.	Small initial scope, acceptance evidence, ownership, operating cost and support.
Improve the process	The work or desired outcome is still unclear.	One observed example, the people involved and which decision or handover causes the problem.

A hybrid can make sense: keep a standard product for common work and build only the missing part. A bespoke application also needs maintenance. A low initial price does not settle the longer-term decision.

an example of a smaller first step

Imagine an operations team retyping approved requests from one tool into another. Both products already meet the team’s needs. The open questions are whether supported interfaces are available and how to handle a request that fails halfway through.

The first experiment could be one handover with test records and a visible exception queue. It does not need to replace both systems. Measure whether it removes the duplicate step without losing the approval or making failures harder to resolve.

Use the buyer checklist to record what must be demonstrated and who accepts it.

bring the brief, keep the question open

Software Facto’s free assessment is a place to explore the problem and a useful first scope. If the simpler route is an existing product or a process change, that is worth establishing before development.

Copy your brief into an email if you want to discuss it. Add a short description of your workflow and systems. The tool does not send your answers automatically.

explore the next step

For the wider context, read what a software factory is and what current AI factory approaches actually automate.

buy, automate,or build?