Before buying software or building a tool, decide whether the workflow itself needs fixing. Use this practical test to choose buy, build, or repair first.
You can usually feel this question before anyone says it out loud.
A workflow is slow. People are chasing updates. Someone is cleaning a spreadsheet every week. A manager wants a dashboard. A founder wants an AI assistant. Someone else has already found a SaaS product that looks close enough.
Then the conversation turns into: should we buy something, build something, or just automate what we already do?
That is a useful question, but it is missing one option. Sometimes the right first move is not to buy or build. Sometimes the right first move is to fix the workflow so that any software decision has a chance of working.
This is especially true with AI. AI can make a good workflow faster, clearer, and easier to operate. It can also make a messy workflow look modern while leaving the real problem untouched.
The choice is not really buy vs build
Most advice on this topic frames the decision as a clean tradeoff. Buying software gives you speed, tested features, and less custom engineering. Building gives you more control, better fit, and more ownership over how the system works.
That tradeoff is real. Thoughtworks describes the classic build-versus-buy dilemma as a choice between proven capability and customization. It is a good frame, but for operators it often starts one step too late.
If the workflow is unclear, buying software will mostly help you move confusion into a new tool. Building custom software will be even more dangerous, because you may end up encoding the wrong process into something that feels permanent.
So the better question is this:
Is the workflow clear enough that software can improve it?
If yes, you can decide whether to buy or build. If no, the workflow needs repair first.
Start with the work, not the tool category
Pick the workflow you are trying to improve and describe it in normal language. Not a system diagram. Not an automation map. Just the actual work.
What starts the workflow? Who receives the request? What information do they need? What decision has to be made? What gets handed off? What happens when something is missing? Where does the final output go?
If the team can answer those questions in a few minutes, you probably have enough shape to evaluate software. If every answer turns into a debate, the tool decision is premature.
This is the part people skip because it feels less exciting than buying a platform or building a custom tool. But it is where most of the value is. A bad workflow does not become a good workflow because it has a nicer interface.
When buying software is probably the right move
Buying software makes sense when the workflow is important but fairly standard.
Think about task management, CRM basics, helpdesk ticketing, scheduling, accounting, payroll, document signing, survey collection, or a simple knowledge base. These are real problems, but most companies do not need to invent their own way of doing them.
Buying is especially attractive when you can live with the tool's opinion about how the work should happen. If the SaaS product expects three stages in a pipeline and your team can reasonably adapt to those stages, great. You get speed, support, upgrades, integrations, and a lower burden on your internal team.
The warning sign is when people say, "This tool is perfect, except we will need to work around it every day."
A few workarounds are normal. But if the core workflow has to bend around the software, buying can become expensive in a quiet way. The license is visible. The daily friction is not.
When building an internal tool is probably the right move
Building starts to make sense when the workflow is specific, valuable, and hard to operate through generic software.
This does not mean building a giant platform. Often the right build is a small internal layer that connects the tools you already use. It might pull data from a CRM, show the right fields to a manager, create a review queue, draft a client update, or give the team one place to approve exceptions.
Custom tools are useful when the work crosses several systems, depends on business-specific rules, or creates a meaningful advantage when done well. A private equity team may need a portfolio reporting workflow that combines company data, commentary, review, and board materials. A professional services firm may need a proposal workflow that pulls pricing, scope, staffing, approvals, and previous examples together. A healthcare or financial services team may need a review workflow where speed matters but human accountability still matters too.
In those cases, buying another standalone tool may create another place to update. A focused build can become the operating layer around the work.
The warning sign is when the team wants to build because buying feels boring. Custom software should earn its keep. If the process is common and the company does not have a special way of doing it, buying is usually better.
When you should fix the workflow first
This is the option most teams underuse.
You should fix the workflow before buying or building when people cannot agree on what the process is, when every case is treated as an exception, when the data definitions keep changing, or when nobody owns the final outcome.
You should also pause when the workflow depends on one person remembering what to do. Software can support judgment, but it cannot replace basic clarity. If only one person understands the edge cases, start by making that knowledge visible.
Fixing the workflow first does not have to mean a six-month process project. It can be very practical. Define the trigger. Remove one duplicate step. Agree on the required data. Decide who reviews the output. Clarify what "done" means. Create a simple version of the workflow that people can actually follow.
Once that exists, the buy-or-build choice gets much easier.
How AI changes the decision
AI lowers the cost of trying ideas. That is useful. It can help draft text, classify requests, summarize documents, identify missing data, support review, and generate first-pass recommendations.
But AI also raises the cost of vagueness. If the workflow has no review criteria, the AI output will be hard to trust. If the data is scattered, the answer will be incomplete. If nobody owns the decision, the assistant becomes another thing people check instead of a system people rely on.
Microsoft's guidance on planning AI agent initiatives is useful here because it pushes teams to look at business impact, feasibility, user pain, and change readiness before building. That is the right instinct. You are not just choosing a tool. You are choosing a workflow that people will have to use.
A simple rule helps:
If AI is producing an output that someone has to act on, design the action and review process before you obsess over the model.
A practical decision test
Here is a simple way to decide what to do next. Take one workflow and answer these questions honestly.
- Is the workflow standard? If most companies do it the same way, buying is probably worth checking first.
- Is the workflow specific to how you create value? If yes, a custom internal tool may be worth it.
- Do people agree on the current process? If not, fix the workflow before committing to software.
- Is the required data available and trusted? If not, the first project may be data cleanup, not automation.
- Does the output have a clear owner? If not, buying, building, or adding AI will all struggle.
- Can you test a small version in a few weeks? If yes, start small and let evidence guide the bigger decision.
The answer may be mixed. That is normal. You might buy a CRM, build a small reporting layer on top of it, and fix the handoff between sales and delivery at the same time. The goal is not ideological purity. The goal is a working system.
Three quick examples
Client onboarding
If the problem is basic task tracking, buy a project management or onboarding tool. If onboarding spans sales, contracts, payments, compliance, delivery setup, and client communication, you may need a custom layer that connects those pieces. If every team onboards clients differently, fix the workflow first.
Management reporting
If the metrics are agreed and the data is clean, buy or configure a BI tool. If the report needs commentary, approvals, exceptions, and recurring operating actions, a more custom workflow may help. If every meeting starts with people arguing about which number is correct, fix the data and definitions first.
AI document review
If the task is generic summarization, an existing tool may be enough. If the review depends on your internal criteria, risk thresholds, client terms, or investment logic, build the workflow around those rules. If nobody can describe what a good review looks like, pause and define the standard before adding AI.
What to do next
Choose one workflow that is visibly slowing the business down. Do not start with the tool. Start with the work.
Write the workflow in plain language. Mark the slow points. List the data needed. Identify who reviews the output. Then decide whether the answer is buy, build, or repair first.
If the workflow is standard, shortlist software. If it is valuable and specific, sketch the smallest internal tool that would make it easier to operate. If the workflow is unclear, spend the first sprint making it clear.
That may feel less dramatic than launching an AI project, but it is usually what makes the AI project worth doing.
How Ubisar helps
At Ubisar, we help teams work through this decision in practice. We look at the workflow, the data behind it, the tools already in place, and where AI would genuinely improve the work.
Sometimes the answer is to configure better software. Sometimes it is to build a focused internal tool. Sometimes the most valuable first move is to repair the workflow and data foundation before anything gets automated.
If you are trying to decide where to start, read how to choose the first workflow to improve with AI, or look at our AI, Data & Tech Implementation Retainer. If you already have a workflow in mind, send it to us and we can help you decide whether to buy, build, or fix first.