Build vs Buy AI: Decide From The Workflow

The build-vs-buy decision gets clearer when it is tied to one revenue workflow. You already know the problem, even if the comparison spreadsheet does not: a lead sits overnight, a quote goes out with no next step, or a renewal risk shows up in a report that nobody is assigned to act on. Until that path has a name, buying and building are both guesses.

Most teams still make the choice too early. They line up model options, engineering estimates, and polished demos before anyone writes down the handoff that is costing money. The meeting turns into a platform argument, and the Monday work stays exactly where it was.

Start with the workflow.

Name the path before you name the platform. The useful candidates are concrete: an inbound lead that should become a booked call, a quote request that should become a proposal, an abandoned cart that should get a follow-up, a support signal that should become a retention task, a renewal risk that should reach an owner, or a sales call that should land in the CRM as something a person can act on the same day.

Once the path has a name, the build-versus-buy question gets practical. You can see which source systems already hold the facts, which person acts next, which fields have to move, and where a failure would show up as missed revenue instead of as a disappointing demo.

Buy when the workflow is already a known job.

Buy when the workflow is common and the value comes from speed, reliability, support, and integrations that someone else will keep working. Email automation, CRM routing, call summaries, lead enrichment, helpdesk triage, product recommendations, and attribution capture usually belong in this group, because the hard part is running them every day.

The buying decision should still be strict. A vendor earns the purchase when it can receive the event you named, write to the system you already trust, show you when it failed, and let your team inspect what happened on a real customer before you widen the rollout. A polished demo does not answer those questions.

Ask the vendor about the path.

• Which event starts the workflow, and can they point to it in your account?
• Which fields does the tool read, and which fields does it write back?
• Can it update the CRM or source system without a manual export?
• What happens when a required field is missing, stale, or conflicting?
• Can an owner review real examples before the workflow expands past the first path?
• If you leave, do you keep the workflow logic, or does it stay locked in their account?

If the vendor cannot answer those questions in plain language, the tool may add a new handoff instead of fixing the one you brought them. That is a reason to walk away from the category, even when the interface is pleasant.

Configure when the platform you already pay for is close.

Many teams do not need a custom build, and they do not need another subscription either. They need the platform they already pay for to be arranged around the path that is failing. That might mean a new CRM property, a routing rule, a prompt template, a webhook, a dashboard the owner will actually open, or a stop rule that sends risky cases to a person.

Configuration is the middle path. It is faster than custom engineering, and it stays more owned than a vendor workflow you cannot inspect. It works best when the core product already does the job and your edge case is mostly about fields, timing, permissions, or review. If the product cannot see the trigger or cannot write the output, configuration will not save it, and you should stop pretending a settings screen is a system.

Build when the judgment is yours.

Build only when the workflow is specific enough that a purchased tool would hide the judgment that matters. That usually means proprietary data a vendor cannot see, an approval rule your customers or regulators expect you to control, a product experience people touch directly, or a path that is part of how you sell and would be ordinary if you rented it.

Even then, build the smallest owned part. Buy the foundation when the foundation is ordinary, use standard APIs where they already do the connection, and build the piece that has to reflect how your business qualifies, prices, routes, or approves. A custom project that rebuilds email, storage, and login is usually a way to spend a year before the original handoff moves.

Count the cost of making the path work.

Do not compare a subscription price with an engineering estimate and call that the decision. Compare the total cost of making this one workflow work, including the weeks after launch when someone has to notice that it stopped.

For a purchased tool, include implementation, integration, admin time, training, contract minimums, export limits, and the cost of switching later when the logic lives in their account. For a custom build, include engineering, testing, security review, monitoring, changes to the source system, prompt or model upkeep, and the cost of every future field change. The expensive choice is usually the one nobody owns after the kickoff meeting ends.

Use the table after the brief is filled in.

Prove it on a narrow path before the contract gets large.

Whether you buy, configure, or build, keep the first release narrow. Use one source, one trigger, one output, one owner, and one number, then review real examples within a week of launch. A wide rollout before that review is how a small uncertainty becomes a system nobody will turn off.

A useful proof does not ask whether the AI was impressive in the meeting. It asks whether the buyer path moved in a way you can point to: faster follow-up, cleaner routing, better qualified calls, fewer missed handoffs, clearer margin, or revenue you kept that used to slip. If none of those moved, the model was not the thing that was missing.

The usual mistakes are easy to spot after the fact.

Teams get this decision wrong when they treat AI as a category purchase instead of a fix for one workflow. They buy while the source data is still too thin to trust. They build a custom system for a job that email or the CRM already does. They configure a clever rule and never name the person who looks when it fails. They measure how much the tool produced instead of whether the path moved.

The better decision is usually less dramatic. Inspect the path, choose the smallest fix you can still own next quarter, and make the first proof visible to the person who feels the miss today.

Choose the fix after the path is clear.

When the workflow, the home system, the owner, and the proof number are written down, the tool debate gets smaller. Buy the standard job, configure the platform you already pay for, or build only the judgment a vendor would hide. If you want a second set of eyes on that brief before you sign anything, start with the free Systems Plan and bring the path you want fixed.