Build versus buy is usually debated as one decision for the whole project. In practice most successful deployments buy the commodity parts — conversation handling, recognition — and build the parts genuinely specific to the business. The useful exercise is identifying which is which.
A question that is usually asked too early
Build versus buy is typically debated as a single, upfront decision — one answer for the whole project. In practice it is rarely binary: most successful deployments buy a platform for the parts that are genuinely commodity (conversation handling, recognition, basic knowledge retrieval) and build the parts that are genuinely specific to the business (deep system integration, unusual workflow logic, proprietary process knowledge).
The useful exercise is not choosing a side. It is identifying, component by component, which parts of the problem are commodity and which are specific — and being honest that the answer usually changes as the project matures from pilot to production scale.
Seven criteria for the decision
Read together, not any one alone — a strong signal on one criterion rarely settles the question by itself.
-
1
Conversation complexity
Standard qualification, FAQ answering, booking flows are well-served by mature platforms that have solved these patterns repeatedly. Deeply workflow-specific logic tied to an unusual internal process may not fit any platform's assumptions cleanly, and forcing it in can cost more than building it directly.
-
2
Integration depth
Reading a few fields from a well-documented API is commodity work most platforms handle well. Deep integration with legacy or unusual internal systems, especially ones with poor documentation, often needs custom engineering regardless of which conversational platform sits on top — see the integration architecture that either approach still needs.
-
3
Knowledge structure
Well-organised, centralised documentation suits most platforms' ingestion assumptions. Highly fragmented knowledge scattered across many incompatible systems may need custom retrieval work that goes beyond what a standard platform's ingestion tooling assumes.
-
4
Compliance and data requirements
Standard data handling needs are usually met by established platforms with existing certifications. Unusual regulatory or data-residency requirements specific to your sector or market may not be met by any available platform at all, which points toward building or toward a hybrid.
-
5
Team capability
An in-house team capable of building and, critically, maintaining a custom system changes the calculation considerably. Without that ongoing capacity, even a technically superior custom build becomes a liability the moment the people who built it move on.
-
6
Time to value
A platform is faster to a working pilot in almost every case. A custom build only closes that gap when the platform genuinely cannot do what is needed, which is worth confirming rather than assuming.
-
7
Differentiation
Is the chatbot itself a competitive differentiator, or a means to an operational end? Most businesses are in the second category, which weighs toward buying, since the value is in the outcome rather than in owning the underlying conversational technology.
What 'buy' actually commits you to
Buying is not a one-time decision that ends at signing. It is an ongoing relationship with its own costs and constraints, worth being realistic about.
- Vendor lock-in risk: how hard is it genuinely to leave, and can your data and configuration be exported in a usable form? This is worth confirming directly during evaluation, as covered in the buying checklist.
- Feature roadmap dependency: you are relying on the vendor's priorities matching yours over time, which they may not.
- Pricing model risk at scale: a per-conversation or per-seat model that looks reasonable at pilot volume may look very different at production volume — model this explicitly before committing.
- Customisation ceiling: every platform has a limit to what configuration can achieve before you hit a wall requiring a workaround or an exception request.
- Ongoing content and configuration ownership: buying the platform does not remove the need for your own team to maintain the knowledge and rules inside it.
The pricing model risk deserves particular attention — a cost structure that looked comfortable during a pilot can become the largest line item in the budget once volume scales, and this should be modelled at two and five times current expected volume before signing anything.
What 'build' actually commits you to
Building has its own ongoing costs, less visible at the start than at the platform's contract renewal but no less real.
- Ongoing engineering maintenance: someone has to own this system indefinitely, not just build it once — and that ownership needs to survive team changes.
- Keeping pace with the underlying technology: the field moves, and a custom system needs deliberate investment to avoid falling behind capabilities a platform would have added automatically.
- Building your own operational tooling: analytics, testing infrastructure, guardrail enforcement, monitoring — all of this exists ready-made in a mature platform and needs building from scratch otherwise.
- Key-person risk: knowledge of a custom system frequently concentrates in a small number of people, and losing them is more disruptive than losing a platform vendor relationship would be.
- Slower time to initial value, in almost every case, which has its own opportunity cost worth weighing explicitly against the long-term flexibility gained.
The operational-tooling point is the one most often underestimated. Testing infrastructure, guardrail enforcement and ongoing quality monitoring are not optional extras — they are necessary for a production system, and building them yourself is a substantial and continuing cost that a platform absorbs as part of its price.
The hybrid pattern most successful deployments actually use
In practice, the most common and most defensible pattern is neither pure build nor pure buy.
-
1
Buy the conversational core
Recognition, dialogue management, basic retrieval — the commodity layer that mature platforms have solved well and repeatedly, where building your own rarely produces a better outcome for the effort involved.
-
2
Build the integration layer where it is genuinely specific
Connections to unusual internal systems, business-specific workflow logic, proprietary process rules — the parts where your business is genuinely different from what a platform assumed.
-
3
Buy the operational tooling
Testing infrastructure, analytics, monitoring — unless you have a specific reason to build these, audit and quality processes are usually better bought than built from scratch.
-
4
Build the knowledge structure that reflects your actual documentation
Even on a bought platform, how your content is organised and maintained is your responsibility and your competitive position, not the vendor's.
-
5
Revisit the split as the project matures
What was correctly bought at pilot scale may be worth building once volume and specificity both increase — this is a decision to revisit, not one to make once and leave.
This pattern is worth naming explicitly during planning, because framing the decision as build-or-buy for the whole project tends to produce either an expensive custom system reinventing commodity work, or a platform strained past what its configuration can reasonably achieve.
Cost comparison, done honestly
Neither option has a fixed cost that applies to every situation — this needs modelling with your own numbers, not a generic industry figure.
- Model platform cost at current volume and at two and five times current volume, since pricing models that look reasonable at pilot scale sometimes do not at production scale.
- Model build cost including ongoing maintenance, not only initial development — the ongoing cost typically exceeds the initial build cost over a multi-year horizon.
- Include the cost of operational tooling in any build estimate, since it is genuinely necessary and easy to omit from an initial estimate.
- Include the opportunity cost of slower time to value in any build estimate — a working pilot delayed by months has a real cost even when it is hard to quantify precisely.
- Include switching cost in any buy estimate — not the sticker price, but what leaving the platform would actually cost if it becomes necessary later.
- Never accept a headline number for either path without the assumptions behind it stated explicitly.
Decision framework and next step
Four questions to work through, in this order.
-
1
Which components of your specific problem are genuinely commodity, and which are genuinely specific to your business?
Score each of the seven criteria independently before combining them into an overall conclusion.
-
2
Do you have the ongoing team capability to maintain a custom build indefinitely, not just to build it once?
Without this, even a well-built custom system becomes a liability once its original builders move on.
-
3
Have you modelled cost for both paths at future scale, not just pilot scale?
The relative economics frequently reverse as volume grows.
-
4
Is a hybrid — buy the core, build the specific integration — the honest answer rather than a pure choice?
This is the pattern most successful deployments actually land on.
Start by identifying which components are genuinely commodity and buy those; build only where your business is genuinely different from what a platform assumed. If buying, the buying checklist covers what to evaluate; our custom software services page covers the build side where it is warranted; our AI solutions overview covers how either path is usually staged.
Frequently asked questions
-
1
Should a business build or buy an AI chatbot?
Neither answer applies to the whole project in most cases. The useful exercise is identifying which components — conversation handling, integration, knowledge structure, compliance, tooling — are commodity and which are genuinely specific to the business, then buying the commodity parts and building the specific ones.
-
2
What criteria determine the decision?
Conversation complexity, integration depth, knowledge structure, compliance and data requirements, in-house team capability, time to value, and whether the chatbot itself is a competitive differentiator — scored independently and read together.
-
3
What does buying commit an organisation to beyond the contract?
Vendor lock-in risk, dependency on the vendor's feature roadmap, pricing model risk at scale, a customisation ceiling, and ongoing responsibility for content and configuration regardless of which platform is chosen.
-
4
What does building commit an organisation to?
Ongoing engineering maintenance indefinitely, keeping pace with underlying technology, building operational tooling from scratch, key-person risk, and typically slower initial time to value.
-
5
What is the most common pattern in successful deployments?
A hybrid: buying the conversational core and operational tooling as commodity work, and building the integration layer and knowledge structure that are genuinely specific to the business — revisited as the project matures rather than decided once.
The decision is rarely binary, and treating it as one is how projects end up either reinventing commodity work at high cost or straining a platform past what its configuration can reasonably support.
