Build, Buy, or Co-Build AI? 10 Questions to Ask Before You Decide

Almost every owner we talk to about AI is circling the same decision: do we build this ourselves, buy a product, or work with a partner to build it together? The honest answer depends less on the technology than on what your business is actually good at. This post is a checklist of questions to ask yourself before you choose. Our answer, after building AI systems for our own business and for others: if technology is not your core competency, co-build with a strong partner.

1. Is technology the thing you sell, or the thing that supports what you sell?

This is the question everything else hangs on. If your company's edge is software, you should probably build your AI capability in-house, because that is where your best people already live. If your edge is furniture, insurance, education, logistics or retail, then AI is a tool that has to serve your core work, and building a software organization around it is a second business you did not plan to run.

For those companies, co-building is the right call. You bring the domain knowledge, the data, and the judgment about what a good outcome looks like. A good technical partner brings a deeper reservoir of practice: the patterns, failure modes and shortcuts that come from having shipped similar systems before. You stay the owner, and you borrow the experience.

2. What does your prototype actually prove?

A quick prototype is easy now. An afternoon with a modern model can produce a demo that looks remarkable. That is real progress, and it is also where many projects go wrong, because the demo hides almost all of the work.

A prototype shows that the model can do the task on a handful of clean examples. It does not show what happens with messy data, concurrent users, expired credentials, a vendor API that changes, a model that gives a different answer on Tuesday, or an employee who does something unexpected. RAND's study of why AI projects fail, built on interviews with experienced practitioners, makes this point about organizations that hop from prototype to prototype: they can end up blind to failures that appear after a model is deployed. The unglamorous infrastructure is what lets you see and fix those failures.

3. Who will own it in month six?

Building is not a one-time event. The first version ships, results start coming in, and now you have to read them, decide what to change, and change it without breaking what works. That iteration is where disciplined engineering earns its keep.

We learned this on our own marketing. We built an AI-assisted marketing system with a simple loop: observe, interpret, recommend, approve, execute, verify, then measure again. Getting something to produce recommendations was the easy part. The hard part was everything around it, and we wrote about it in Building a Marketing System That Improves Itself and Automation Was the Easy Part. A few examples of what that meant in practice:

• Every material recommendation ends in one of five outcomes (continue, change, test, stop, or escalate), so people and software share one vocabulary for decisions.

• Each decision gets a stable identifier, which is what lets us connect a recommendation to what was executed and to what we measured afterward.

• A failed execution stays recorded as failed. A corrective follow-up can inherit approval only within the original scope, so a retry never quietly becomes a bigger change.

• Each fact has one authoritative source, and different channels get reviewed at different speeds, because daily and slow-moving signals should not be judged on the same clock.

None of that is exciting, and none of it came from the model. It came from running the system, watching where it went wrong, and fixing the process. If you are not going to have someone who owns that loop, plan for the project to stall after the pilot.

4. Where does it touch your real systems and data?

An AI feature that lives in a chat window is one thing. An AI feature that reads your orders, writes to your records, or talks to your accounting or ERP system is a systems integration project with an AI component. That means authentication, permissions, retries, data quality, audit trails and a plan for when a connected system is down.

We saw the ordinary version of this in our own platform. Ansible is the Symfony-based operations platform we use to run Endertech. Over roughly the last fourteen months it has grown to cover a CRM, ticketing, project management with a sprint board, a client portal, integrations such as accounting, prospecting data and publishing, tooling to import our projects out of Jira, and a handful of AI features such as proposal drafting. Our own commit history shows how much of that work was plumbing: a stretch of fixes around login and token refresh behavior after releases, a pass to remove slow database query patterns once real data piled up, and a refactoring round to reorganize code that had been written quickly. None of those were AI problems. They are the cost of making anything reliable, and AI features inherit all of them.

If your project connects to systems like these, it helps to have people who have done the surrounding work many times. Our database-driven web apps and AI agent orchestration work is mostly this layer.

5. Where must a human stay in the loop?

Decide this before you build, not after the first incident. Which actions can the system take alone? Which need a person to approve? What happens when the approver does not respond? A prototype rarely answers these questions, and answering them later is more expensive.

In our own work, the line we drew is that AI can propose and prepare, and people keep the irreversible steps. Recommendation is not approval, approval is not execution, and execution is not verification. We go deeper on this in Where Should a Business AI Workflow Require Human Approval?

6. How will you know it is working?

Before you pick build, buy or co-build, write down what success looks like in plain terms and how you will measure it. Without that, you cannot tell a useful system from a convincing one. A good first project is narrow enough to measure, which is the subject of How to Choose the First Business Workflow for AI Automation.

7. Has anyone on the team shipped this kind of thing before?

This is the experience question. Models change quickly, but the engineering problems around them (access control, evaluation, rollbacks, cost control, monitoring) change slowly. People who have already lived through those problems make fewer expensive mistakes. If you have such people in-house and they have capacity, that is a strong argument for building. If you do not, you are paying to learn on your own project.

8. What does the research say, and how far can you trust it?

A few studies are relevant. We want to be careful with them, because they have been stretched well beyond what they show.

MIT NANDA, “The GenAI Divide: State of AI in Business 2025.” This report, by Aditya Challapally, Chris Pease, Ramesh Raskar and Pradyumna Chari, is a preliminary working paper, not a peer-reviewed study. It draws on 52 interviews, 153 survey responses from senior leaders, and a review of more than 300 public initiatives, with self-reported outcomes. In that sample, external partnerships reached deployment about 67% of the time, versus about 33% for tools built internally. The authors themselves caution that the results rely on self-reported outcomes, may not account for confounding factors, and may reflect organizational capabilities rather than the approach alone. They do not claim it proves causation. Also note that “partnership” in the report mostly means buying or co-developing with vendors, not specifically hiring an agency, and the authors work on agentic AI themselves. The report's most viral headline has been widely misread, and critics have explained why. We do not rely on it. The 67 versus 33 comparison is one data point, and it matches what we see in practice.

BCG. A BCG survey of 270 organizations found that those combining in-house teams with external vendors reported more satisfaction and productivity than those going it alone, and that in-house-only teams reported less cost savings. Note that this favors a hybrid, with your people and a partner working together, not a handoff. BCG is also a consulting firm, so it has its own perspective.

RAND. RAND's interviews with 65 data scientists and engineers explain why many AI projects fail. The top root cause was leadership misunderstanding or miscommunicating what problem AI was meant to solve; the others were missing data, chasing technology over the problem, weak infrastructure, and asking AI to do things it cannot yet do. Its scope was machine learning projects and did not include simply prompting pretrained models, so treat it as context rather than a verdict on every AI use.

The common thread: most AI projects stall for organizational and implementation reasons, and working with experienced people appears to help. It does not show that agencies beat internal teams.

9. When is buying a tool enough, and when should you co-build?

Buy a tool or keep it simple in these cases:

• Individual productivity. Rolling out a general-purpose assistant to your staff for drafting, summarizing and research is a buy decision. Do it yourself, set a usage policy, and move on.

• Commodity tasks. If a mature product already does the job well and fits your workflow, buy it. Building a worse version of an existing tool is rarely worth it.

• You have a strong engineering team with spare capacity and people who have shipped AI features to production. Build, and bring in a partner for specific gaps or a second opinion.

• The project is truly small and low-risk. A throwaway internal script needs nothing more than a script.

Co-build when AI has to work every day inside your operations, touches your core systems, and technology is not your core competency. That is the case where the gap between a demo and a dependable system is widest.

10. What would a good co-build look like?

Look for a partner who works with you rather than for you. You should keep ownership of the problem definition, the data, and the decisions. The partner should be willing to explain tradeoffs in plain language, push back on scope that is not worth building, put approval gates and measurement in from the start, and leave you with systems your own team can understand. A partner worth hiring will be direct about tradeoffs and will own the outcome with you.

If you are building something that will connect AI to your business systems, our MCP server development work covers the access layer, and the autonomous content pipeline we built with a human publication gate shows what that looks like in practice.

FAQ

Is building AI in-house always cheaper?

Not necessarily. Building can look cheaper because the license fee is zero, but the full cost includes engineering time, maintenance, monitoring, and the cost of mistakes. BCG's survey reported less cost savings for in-house-only teams, though that is survey data, not a guarantee for your project.

What does co-build mean?

Co-build means you and an outside team build a custom system together. You own the goals, data and decisions. They contribute engineering experience, architecture and delivery discipline. Ideally your team can run and extend the result afterward.

Does the MIT report prove that partnerships work better?

No. It is a preliminary, self-reported working paper based on a small sample, and the authors say the results may reflect organizational capabilities and do not prove causation. We treat it as a single suggestive data point.

Can we start with a prototype ourselves and bring in a partner later?

Yes, and many teams do. A prototype is useful for learning what you want. Just treat it as a prototype: plan for the reliability, integration and measurement work that comes after, and be willing to rebuild parts of it.

A soft next step

If you are weighing build, buy, or co-build for something specific, we would be glad to talk it through and help you map the right path. You can reach us through the contact page.