Building With AI vs. Buying AI: What the Vendor Pitch Doesn't Tell You

Every AI vendor will tell you that buying is obvious: proven product, fast deployment, someone else's problem when it breaks. Every AI developer will tell you that building is obvious: full control, competitive differentiation, no licensing lock-in. Both arguments have merit. Both arguments are also, in their own way, self-serving.

The build-vs-buy decision in AI is one of the more consequential technology calls a business will make in the next few years, and most organisations are making it without a clear framework for thinking it through. So here's an honest attempt at one, from someone who has done both and has the scars to prove it.

What "Buying" Actually Means Now

The AI software market has matured quickly enough that "buying" now covers a spectrum that didn't exist two years ago.

At one end, you have fully managed SaaS products: a customer support AI, a document processing tool, a meeting summariser. You connect it to your systems, configure it within the bounds the vendor has designed for, and you're live. These are fast to deploy and genuinely useful within their scope. Their limitation is exactly that scope: the product does what the vendor designed it to do, and the moments where your business needs something slightly different from the standard configuration are moments where you'll feel the edges.

In the middle, you have AI platforms: tools like OpenClaw, n8n, or similar orchestration layers that give you configurable agents and workflows without requiring you to write the underlying model code. These are closer to buying infrastructure than buying a product, and they require more investment to configure properly, but they give you substantially more flexibility. This is where a lot of the interesting SME automation work is happening right now.

At the other end, you have foundation model API access: calling Claude, GPT, or Gemini directly and building your own application layer on top. This is building, not buying, regardless of the fact that you're paying a per-token fee. You own the logic, the workflow, the interface, and the integration.

Most build-vs-buy discussions conflate these three things, which is why the conversations tend to generate more heat than light.

The Real Costs of Buying

The headline cost of a SaaS AI product is the subscription. The actual cost is the subscription plus the integration work, plus the configuration time to make it fit your workflows, plus the ongoing cost of working around the things it doesn't do quite right for your context.

None of those secondary costs appear in the vendor pitch. They appear three months into the deployment when someone has spent more time maintaining the integration than it would have taken to build the thing properly in the first place.

The other cost that doesn't appear in the pitch is dependency. When your operations are built around a third-party product's data model, its API structure, and its pricing decisions, you've created a dependency that has a value to someone other than you. Vendors change pricing. They deprecate features. They get acquired. The cost of unpicking a deeply embedded tool is always higher than it looked when you were signing up.

None of this means buying is wrong. It means the total cost of ownership calculation needs to include things the vendor's ROI calculator won't show you.

The Real Costs of Building

Building has its own version of the same problem: the costs that don't appear in the initial enthusiasm.

The most common one is scope creep driven by possibility. When you're building on foundation models, the capability ceiling is high enough that it's very easy to keep extending the scope of what you're building, because each new thing feels like a small addition. The project that started as an invoice processing agent becomes an invoice processing agent with a custom admin panel, a document management layer, a reporting dashboard, and a webhook integration framework. Each addition was individually justifiable. The cumulative cost is considerably more than anyone planned for.

The second is maintenance. A bespoke AI application is a piece of software, and software requires ongoing maintenance. Models get updated, APIs change, the business requirements evolve. Someone has to own that. If your build relies on a single developer or a single external contractor, you've traded vendor dependency for a different kind of dependency that may be harder to manage.

The third, and the one most people underestimate, is prompt engineering as an ongoing discipline. The initial prompts that make an application work well are not the prompts that will make it work well six months later when the model has been updated, the use cases have expanded, and the edge cases have multiplied. Good AI applications require ongoing iteration on the reasoning layer, and that work requires someone with the skill and the time to do it properly.

I've built production AI applications from the ground up, including a voice-first executive mentorship platform built on Cloudflare Workers with ElevenLabs voice integration and a RAG knowledge base built from decades of published work. That project required solving problems across persona engineering, real-time audio infrastructure, session management, document intelligence, and a 4-stage conversational methodology. None of those problems were hard in isolation. Solving all of them together, to a production standard, without a team, took considerably longer than a naive estimate would have suggested. The end result was worth it. The timeline was not what anyone would have called efficient.

I say that not to discourage building, but to be honest about what it actually involves.

The Framework That Actually Helps

Rather than defaulting to one camp or the other, the question worth asking is: what is the nature of the competitive advantage this AI application is supposed to create?

If the advantage is operational efficiency on a problem that's broadly similar across businesses in your industry, buying is almost certainly right. You don't need a custom invoice processing system when three credible products already solve that problem. The configuration cost is real but bounded, and you benefit from the vendor's ongoing product development without carrying the cost.

If the advantage is differentiation based on something specific to you: your data, your methodology, your proprietary knowledge, your particular way of serving customers, building is almost certainly right. A bought product can't encode the intellectual framework of a specific futurist's forty years of strategic thinking. It can't represent the specific operational knowledge that lives inside your business in a way that creates genuine competitive value. Those things require building, and the build cost is justified by the fact that the output is, by definition, not something a competitor can simply buy.

The cases where this framework produces a clear answer are also the cases where the decision is easiest. The genuinely hard cases are in the middle: where an off-the-shelf product gets you 70% of the way to what you need, and you have to decide whether the remaining 30% is worth building for, or whether you can live with the gap.

My honest observation from both sides of this decision is that most businesses underestimate how much the 30% gap matters when it involves customer-facing differentiation, and overestimate how much it matters when it involves internal operational efficiency. Getting those two assessments the right way around is most of the decision.

A Practical Starting Point

Before committing to either path, it's worth spending a few hours with a clear-eyed person who has experience on both sides, mapping the specific application against the three questions that actually drive the decision: How differentiated does this need to be? Who will maintain it? And what happens to the business if the vendor or the builder is no longer available?

The answers to those three questions will tell you more about the right call than any vendor comparison matrix or developer portfolio.

I work on both sides of this decision: advising on tool selection and AI strategy, and building bespoke applications when that's the right call. If you're trying to work out which path makes sense for something specific, I'm happy to have a straight conversation about it.title: "Building With AI vs. Buying AI: What the Vendor Pitch Doesn't Tell You" slug: building-vs-buying-ai-what-vendors-dont-tell-you feature_image: /content/images/build-vs-buy-ai.jpg meta_title: "Build vs Buy AI: The Honest Guide for Business Leaders" meta_description: "Every AI vendor makes buying look easy and building look unnecessary. The reality is more nuanced, and getting this decision wrong is expensive either way." tags:

• AI
• Strategy
• Technology
• Product
• Leadership published: true excerpt: "The build-vs-buy decision in AI is more consequential than it's ever been, and most of the advice on it comes from people trying to sell you one of the two options."

Every AI vendor will tell you that buying is obvious: proven product, fast deployment, someone else's problem when it breaks. Every AI developer will tell you that building is obvious: full control, competitive differentiation, no licensing lock-in. Both arguments have merit. Both arguments are also, in their own way, self-serving.

The build-vs-buy decision in AI is one of the more consequential technology calls a business will make in the next few years, and most organisations are making it without a clear framework for thinking it through. So here's an honest attempt at one, from someone who has done both and has the scars to prove it.

What "Buying" Actually Means Now

The AI software market has matured quickly enough that "buying" now covers a spectrum that didn't exist two years ago.

At one end, you have fully managed SaaS products: a customer support AI, a document processing tool, a meeting summariser. You connect it to your systems, configure it within the bounds the vendor has designed for, and you're live. These are fast to deploy and genuinely useful within their scope. Their limitation is exactly that scope: the product does what the vendor designed it to do, and the moments where your business needs something slightly different from the standard configuration are moments where you'll feel the edges.

In the middle, you have AI platforms: tools like OpenClaw, n8n, or similar orchestration layers that give you configurable agents and workflows without requiring you to write the underlying model code. These are closer to buying infrastructure than buying a product, and they require more investment to configure properly, but they give you substantially more flexibility. This is where a lot of the interesting SME automation work is happening right now.

At the other end, you have foundation model API access: calling Claude, GPT, or Gemini directly and building your own application layer on top. This is building, not buying, regardless of the fact that you're paying a per-token fee. You own the logic, the workflow, the interface, and the integration.

Most build-vs-buy discussions conflate these three things, which is why the conversations tend to generate more heat than light.

The Real Costs of Buying

The headline cost of a SaaS AI product is the subscription. The actual cost is the subscription plus the integration work, plus the configuration time to make it fit your workflows, plus the ongoing cost of working around the things it doesn't do quite right for your context.

None of those secondary costs appear in the vendor pitch. They appear three months into the deployment when someone has spent more time maintaining the integration than it would have taken to build the thing properly in the first place.

The other cost that doesn't appear in the pitch is dependency. When your operations are built around a third-party product's data model, its API structure, and its pricing decisions, you've created a dependency that has a value to someone other than you. Vendors change pricing. They deprecate features. They get acquired. The cost of unpicking a deeply embedded tool is always higher than it looked when you were signing up.

None of this means buying is wrong. It means the total cost of ownership calculation needs to include things the vendor's ROI calculator won't show you.

The Real Costs of Building

Building has its own version of the same problem: the costs that don't appear in the initial enthusiasm.

The most common one is scope creep driven by possibility. When you're building on foundation models, the capability ceiling is high enough that it's very easy to keep extending the scope of what you're building, because each new thing feels like a small addition. The project that started as an invoice processing agent becomes an invoice processing agent with a custom admin panel, a document management layer, a reporting dashboard, and a webhook integration framework. Each addition was individually justifiable. The cumulative cost is considerably more than anyone planned for.

The second is maintenance. A bespoke AI application is a piece of software, and software requires ongoing maintenance. Models get updated, APIs change, the business requirements evolve. Someone has to own that. If your build relies on a single developer or a single external contractor, you've traded vendor dependency for a different kind of dependency that may be harder to manage.

The third, and the one most people underestimate, is prompt engineering as an ongoing discipline. The initial prompts that make an application work well are not the prompts that will make it work well six months later when the model has been updated, the use cases have expanded, and the edge cases have multiplied. Good AI applications require ongoing iteration on the reasoning layer, and that work requires someone with the skill and the time to do it properly.

I've built production AI applications from the ground up, including a voice-first executive mentorship platform built on Cloudflare Workers with ElevenLabs voice integration and a RAG knowledge base built from decades of published work. That project required solving problems across persona engineering, real-time audio infrastructure, session management, document intelligence, and a 4-stage conversational methodology. None of those problems were hard in isolation. Solving all of them together, to a production standard, without a team, took considerably longer than a naive estimate would have suggested. The end result was worth it. The timeline was not what anyone would have called efficient.

I say that not to discourage building, but to be honest about what it actually involves.

The Framework That Actually Helps

Rather than defaulting to one camp or the other, the question worth asking is: what is the nature of the competitive advantage this AI application is supposed to create?

If the advantage is operational efficiency on a problem that's broadly similar across businesses in your industry, buying is almost certainly right. You don't need a custom invoice processing system when three credible products already solve that problem. The configuration cost is real but bounded, and you benefit from the vendor's ongoing product development without carrying the cost.

If the advantage is differentiation based on something specific to you: your data, your methodology, your proprietary knowledge, your particular way of serving customers, building is almost certainly right. A bought product can't encode the intellectual framework of a specific futurist's forty years of strategic thinking. It can't represent the specific operational knowledge that lives inside your business in a way that creates genuine competitive value. Those things require building, and the build cost is justified by the fact that the output is, by definition, not something a competitor can simply buy.

The cases where this framework produces a clear answer are also the cases where the decision is easiest. The genuinely hard cases are in the middle: where an off-the-shelf product gets you 70% of the way to what you need, and you have to decide whether the remaining 30% is worth building for, or whether you can live with the gap.

My honest observation from both sides of this decision is that most businesses underestimate how much the 30% gap matters when it involves customer-facing differentiation, and overestimate how much it matters when it involves internal operational efficiency. Getting those two assessments the right way around is most of the decision.

A Practical Starting Point

Before committing to either path, it's worth spending a few hours with a clear-eyed person who has experience on both sides, mapping the specific application against the three questions that actually drive the decision: How differentiated does this need to be? Who will maintain it? And what happens to the business if the vendor or the builder is no longer available?

The answers to those three questions will tell you more about the right call than any vendor comparison matrix or developer portfolio.

I work on both sides of this decision: advising on tool selection and AI strategy, and building bespoke applications when that's the right call. If you're trying to work out which path makes sense for something specific, I'm happy to have a straight conversation about it.