Keep and adjust
Simplify the process or the rules around the existing tools.
Decision framework
Buy or build AI software: how to decide.
Start with the operational problem, then compare the simplest credible options. Use the same requirements, full running costs and ownership questions for an existing tool and a custom AI workflow.
The real question
What exactly are you fixing?
“Which tool should we buy?” and “Should we build our own?” both skip a step. Write the operational problem in one sentence and identify what it costs today: time, errors, delays or missed work.
Map the existing steps before selecting software. Duplicate entry, unclear ownership and unnecessary approvals can be cheaper to remove than to automate.
Four options
The choice is wider than buy or build.
Configure or extend
Use more of the software you already pay for.
Buy
Choose an established product for a standard process, after checking its limits.
Build
Consider custom software when the process is specific, stable and valuable enough.
Five questions
What usually decides the answer.
Is this process standard or specific to your business? How stable is it? What will each option cost over three years? What happens if you leave the vendor? Who owns the system after launch?
A low initial invoice does not settle the comparison. Include setup, seats, integrations, maintenance, migration, internal time and an exit path.
Compare like for like
Use one requirement set for every option.
| Criterion | Evidence to collect | What can change the decision |
|---|---|---|
| Workflow fit | Representative tasks, required fields and cases that do not follow the standard path. | A standard product can fit the core task while requiring costly workarounds around exceptions. |
| Integrations and information | Verified API access, ownership of source information and realistic sample records. | An unavailable interface or poor source information can block either option. |
| Cost over time | Setup, licenses, usage, internal review, support, migration and exit costs over the same period. | A change in users or transaction volume can reverse an apparent price advantage. |
| Control and responsibility | Who approves outputs, investigates failures and owns the operational decision. | A workflow with serious error consequences may need more review than the team can sustain. |
| Change and exit | Export formats, account ownership, supported customization and a practical migration path. | An acceptable tool today may become hard to replace; custom software also creates maintenance obligations. |
| Team capacity | A named operational owner and access to appropriate technical support. | Without ownership, both a subscription and a custom application can become unused overhead. |
Mark requirements as essential or optional before reviewing demos. Compare evidence from the same sample tasks, not lists of features.
Try before committing
Run the same five cases before buying or building.
For a service enquiry workflow, give every shortlisted option the same synthetic inputs. Decide what counts as a pass before the demo.
| Case | Input | What a pass looks like |
|---|---|---|
| Ordinary request | A complete synthetic enquiry. | A stored request, a stable reference and a visible receipt. |
| Missing information | The enquiry without a required field. | A clear correction request; no invented replacement. |
| Repeated event | Replay the same event reference. | No unintended duplicate action downstream; the outcome remains traceable. |
| Destination unavailable | Make the test CRM or downstream service unavailable. | The received request stays recoverable; an owner can see the failure. |
| Recovery | Restore the test destination and retry the failed operation. | The correct record is processed with a traceable outcome and no unintended repeat action. |
This is a proposed test protocol, not a claim that each tool provides these controls. A second legitimate enquiry from the same person is different from replaying the same event. Test failures in an isolated environment, using synthetic records.
Read the evidence
Received, synchronized and answered are different outcomes.
For each option, record the observation, supporting evidence, reviewer and unresolved limitation. A successful screen message does not establish that the request can be found later. A database record does not establish that an operator read the alert or answered the prospect.
On this website, the 7 October 2026 production check used one labelled synthetic request. It was stored in Supabase, then the scheduled worker created one matching Brevo opportunity and sent an internal alert recorded as delivered by Brevo. The human inbox was not inspected at that checkpoint; a follow-up check on 10 October found the alert in the inbox, still marked unread. The test establishes that sequence, not revenue, a qualified lead or every possible recovery scenario.
Analytics was declined for that submission. The operational enquiry was still processed; analytics collection and the commercial record have separate purposes. A contact-link click should not be counted as a confirmed enquiry.
Make the decision
Include the work left for people.
Compare the essential cases that passed, the actions left to the operator and the cost of keeping the workflow usable. Include time spent spotting errors, correcting drafts and recovering interrupted work.
If a form, a reliable record and a named owner solve the problem, start there. An AI step needs a defined task that benefits from interpretation and an output someone can check; it is not automatically needed for routing a request.
Write the decision in one sentence: choose this option for this workflow, because these essential cases passed, with these remaining limits and this owner. If the evidence is missing, run a bounded test before committing to a wider system.
Hypothetical costs
A three-year comparison.
Illustrative assumptions: a tool at $40/user/month plus $3,000 setup; a custom build at $18,000, $600/year hosting and 15% of build cost in annual maintenance from year two. These are not vendor quotes.
| Scenario | Year 1 | Year 2 | Year 3 | Total |
|---|---|---|---|---|
| Buy · 20 users | $12,600 | $9,600 | $9,600 | $31,800 |
| Build | $18,600 | $3,300 | $3,300 | $25,200 |
| Buy · 8 users | $6,840 | $3,840 | $3,840 | $14,520 |
At 20 users, the custom option is lower in this deliberately simplified example; at eight users, buying is lower. Feature changes, integration work, migration, internal time, taxes and AI usage are not modelled here and must be added to a real decision. The maintenance percentage is an assumption for this arithmetic exercise, not a market benchmark or Klicky’s pricing.
Which way to go
Match the option to the process.
Buying often fits
The process is standard, a tool covers the important requirements and the team cannot own custom software.
Building can fit
The process is specific and stable, workarounds are costly, and someone can own the system over time.
Where AI fits
AI may help with drafting and unstructured information. It adds evaluation, human review and running costs; it does not remove the need for a clear process.
Decision checklist
Put the decision on one page.
Before signing
A short decision document should make the assumptions inspectable.
- Problem stated clearly, with a baseline
- Process simplified before automation
- Four options considered
- Three-year costs and assumptions
- Exit path and ownership checked
- A named owner and a reversible first step
Before signing, assign an owner to every acceptance check and test the same ordinary, incomplete and conflicting examples against each shortlisted option. Keep the original inputs and record corrections, review effort and the fallback if a supplier or model fails.
When AI is involved
A useful draft still needs an operating model.
Evaluate the actual task
Use authorized examples that include ordinary, incomplete and ambiguous inputs. Check the information and action the business needs, not only whether the text reads well.
Cost the human review
Identify who checks a draft, how long corrections take and which actions require explicit approval. Include that work when comparing a vendor product with a custom workflow.
Plan the fallback
Define what the operator sees when a model, integration or source is unavailable. A manual route and a clear error state matter in either approach.
Illustrative decision
Sometimes the first step is not a build.
In the fictional onboarding example, requests are copied between email, a spreadsheet and a CRM. The first proposed intervention is one intake form, a shared checklist and an accountable owner in the existing CRM. That tests whether the handoff problem can be solved before adding an AI layer.
The next decision would depend on observed missing information, review effort and remaining duplication. If the simpler process is sufficient, stop there. If one well-defined task still justifies automation, test that task before replacing the wider platform.
This is a teaching scenario, not a documented client decision or a measured result.
Apply the framework
Move from comparison to a useful next step.
Work through the decision
Bring the workflow and competing options. Consulting helps clarify the evidence and what deserves investment.
Explore AI consultingScope one priority problem
A Decision Sprint provides the process map, options, costs and written implementation plan for one bounded decision.
See the Decision SprintEstimate the full cost
Separate setup and delivery from licenses, usage, human review and ongoing care.
Read the AI implementation cost guide
Entrepreneur and AI consultant, I help service businesses improve their operations. I turn software choices into practical plans. My team at Klicky builds what we decide.
About the author ↗From reading to doing
What would change if this workflow worked?
Start with a free 20-minute conversation about the problem, the people and the practical constraints.
Book a discovery call ↗