Mufasa Labs
← BlogStrategyAugust 23, 2026

Build vs buy AI

Build vs buy for AI is total cost, control, and whether the workflow is your edge. Put do-nothing on the same page. Kickbacks make the math a lie.

Build versus buy is not a personality test. It is total cost, control, and whether the workflow is how you make money or stay legal. If the advisor earns on the license, the answer was buy before anyone opened a laptop.

We put three numbers on one page and take no kickbacks. That is the rule on enterprise AI consulting. Delivery, if you want it, is a separate fixed-scope build in your cloud and your repos. It is not bundled into the advice so the advice can stay honest.

Put three numbers on one page

Buy. License, implementation, integration, training, and the people who will run it after the vendor leaves. Include the renewal. Include the modules you will not turn on. Include the identity and logging work the datasheet assumed you already had.

Build. Hours to a first production slice, infrastructure, evaluation, and who maintains it when the original builders move on. Include the cost of being wrong and rewriting. Include the model API if you are not training your own weights. Most "builds" are assemblies.

Do nothing. The hours and error cost of the current process, plus the risk of the shadow tools already in use. If the process is rare and cheap, do not build or buy. Twelve events a year will not pay for a program.

If a vendor or consultant will not fill all three, they are selling a preference. If they fill buy and skip do-nothing, they are hiding the option that makes them unnecessary.

Write the units. Hours times loaded rate. License times seats times years. Error cost if you have even a rough number. A page of adjectives is not math.

Buy when the workflow is not your edge

Commodity drafting, meeting notes, generic search over a clean corpus, a copilot that sits next to a suite you already pay for: buy, then govern. You will not win by rebuilding a chat box. Your competitors can buy the same box tomorrow.

Buy when a product already sits on your system of record and the permissions model matches how you already work. Buying a tool that needs a new identity stack, a new ticket system, and a new warehouse is a build in disguise. Count those months in the buy column.

Buy when speed matters more than fit and the vendor will accept your data-residency, retention, and logging requirements in writing. If they will not sign that, you are not buying software. You are renting a black box and hoping the auditor is busy.

Buy when you have already tried to staff a build and you do not have the people. A half-built internal tool with one hero engineer is not cheaper than a product. It is a single point of failure with a cute name.

Build when the workflow is how you make money or stay legal

Claims, underwriting, clinical documentation, pricing, anything that has to respect your permissions and your audit trail: build or assemble in your cloud. The model can be an API. The retrieval, the permissions, the eval, and the write-back should be yours. If you vanished, the system should still run.

Build when the last three tools you bought did not fit the desk. The problem is not "we need AI." The problem is the process is specific and vendors sell generic. Another generic layer will not fix a process they have never sat in.

Build the smallest slice that can take a live ticket with a human in the loop. A six-month platform before the first ticket is how builds become lakes. The lake then becomes the strategy. Nobody can find the original workflow.

Build when exit matters. If a regulator or a customer can force you to move, you need the workflow logic in a repo you control. A prompt in a vendor UI is not an exit plan.

Hybrid is the usual honest answer

Buy the model. Build the retrieval, permissions, eval, and workflow glue. Buy the ticket system. Build the step that writes back with an audit log. Buy the cheap internal summarizer. Build the path that touches customer data.

"Buy the platform and configure" is still a build if you need six months of professional services. Count those hours in the buy column so you do not surprise finance in month four.

"Build" that secretly depends on one vendor's unreplaceable API is buy with extra steps. Write the exit on the same page as the choice. If you cannot name the replacement, you bought a department.

Hybrid also means sequencing. You can buy a thin tool this quarter to stop the bleeding and build the real path next quarter. That is not indecision. That is a roadmap. What does not work is buying a suite so large it pretends to be the sequence.

Decision rules that survive a board meeting

If the workflow happens rarely, do nothing or buy a lightweight tool. Do not staff a team.

If readiness is low on data or governance, do not buy a suite to paper over it. Fix the floor: source of record, access list, allow-and-deny list. Then choose. A platform on top of unknown permissions is a leak with invoices.

If two vendors need a bake-off, time-box it and keep a build option on the page so the bake-off cannot hold the roadmap hostage. Bake-offs without a do-nothing and a build number exist to waste a quarter.

If the only person who can operate the buy is the vendor, you did not buy. You outsourced a department. Price the retainers, the wait time, and the change orders.

If your consultant's answer is always buy, check their partner list. If their answer is always build, check whether they sell hours. Independent means they can lose the next contract either way. Ask them to show a recent no.

If the first workflow is still unnamed, you are not ready for build or buy. You are ready for a use-case ranking and a kill list.

How we run the conversation

We will not give you a SKU. We will tell you which column is honest for the first workflow after we have seen the system of record and the owner. Sometimes the answer is wait. Sometimes it is a two-week prove on a bought tool with logging you control. Sometimes it is a fixed-scope assembly in your cloud.

No license kickbacks. Month-to-month or a capped statement of work. If we later build, that is a new decision with its own number, not a prize for picking us.

After you choose, write the choice and the three numbers into the roadmap. Revisit at renewal and after the first metric moves. A choice that cannot be revisited is a religion.

How we run the decision and the first prove step, without a license attached, is on enterprise AI consulting.

Want this working in your business?

Every post on this blog comes from systems we've actually built. Book a 30-minute call and we'll map the same playbook to your stack.