AI Assist
"Buy off the shelf or commission a build" sounds like a budget question. It is really a question of how closely your business resembles the average one. Off-the-shelf products are made for the average case — and when you fall inside it, that is the smartest purchase on the market. The trouble starts when you fall outside it and only realise that after paying for an annual subscription.
Let us be honest about it: where the boundary sits, what each option really costs over two years, which expenses both camps keep quiet about, and why the most common right answer is not "either/or" but a third option.
What "ready-made" actually means
The market uses "ready-made solution" for at least three different things, and the confusion is expensive.
A scenario builder. You assemble the branch tree yourself with a mouse: buttons, messages, conditions. Cheap, fast, full control over the logic — but you have to build that logic, and there is no language understanding in it. A classic for FAQs and menus.
A SaaS support platform. A finished product with its own operator interface, request queues, templates and a built-in AI module. You connect channels, upload a knowledge base and go. This is the most "boxed" option: many features from day one, but you live by the platform's rules.
An industry-specific product. A bot built for one niche — salons, dentistry, delivery. It already understands the domain: what a "stylist", a "slot" or a "service" is. If your niche matches, this is the fastest possible start.
What all three share: you are buying someone else's model of your business. If it matches reality, you save a great deal of money. If it does not, you are paying to bend your business to fit someone else's model.
What a custom build actually includes
Custom is not "the same thing, but pricier". It is a different mix of work, and most of the budget goes somewhere people do not expect.
On a real project the split usually looks like this: roughly a quarter of the time on gathering and structuring the knowledge base, another quarter on integrations with your systems, about as much again on designing scenarios and the limits of authority, and only the remainder on the bot code and interfaces themselves. In other words, you are mostly paying for the system to know your business and to work with your data.
What you get in return:
- logic that follows your processes rather than the other way round;
- integrations with the systems you actually run, homegrown ones included;
- your data stays yours: dialogue history, knowledge base and analytics;
- no volume ceiling — costs do not jump when requests double;
- the ability to change behaviour without waiting for a vendor's roadmap.
The main drawback is equally obvious: a larger entry budget and a longer start. Plus dependence on a contractor, which we will cover honestly below.
Where a ready-made product hits its ceiling
In our experience businesses move from a box to a custom build along five typical routes. If you recognise yours, you are already at the edge.
1. The integration that does not exist. The most common reason. The platform supports twenty popular CRMs while you run a homegrown database, an industry accounting system or 1C. The vendor honestly says "it's possible via the API" — and it turns out the API is missing, or one-way, or the adaptation costs half a build.
2. You need live data. A box can answer from uploaded text. But the client is not asking "what are your prices in general", they are asking "is this model in stock right now". If the system cannot see inventory mid-conversation, it either stays silent or lies — and the second is worse.
3. The process is bigger than a dialogue. Booking a stylist is a dialogue. Taking a repair request where you must check the warranty, pick a service centre, reserve a part and generate a document is a process. Off-the-shelf products were designed for conversations, not processes.
4. Volume made the subscription pricier than a build. Per-dialogue pricing looks harmless at a thousand requests and starts to hurt at ten thousand. That is pure arithmetic, and it is easy to check — see the calculator below.
5. The bot became part of the product. If you sell a service with a bot inside it, handing that bot to someone else's platform means handing over control of your own product quality and your clients' data.
Walk through the decision tree — it follows exactly these forks and shows not only the verdict but the path you took to it.
What it costs over two years
The most common mistake when choosing is comparing a one-off build price against a monthly subscription. That comparison means nothing: the first sum is final, the second is recurring and grows with you.
The correct approach is total spend over a fixed horizon. Two years is a sensible one: over a shorter period custom almost always loses, over a longer one it almost always wins, and twenty-four months shows the real picture for most businesses.
Move the sliders to your own numbers. The model is built on average market SaaS pricing and our real quotes.
Watch how the chart behaves: the break-even point shifts left mainly because of dialogue volume and the number of managers in the system. Those are what platforms charge the most for. If you have a modest flow and one or two operators, the box wins comfortably — and that is a perfectly good outcome.
The hidden costs of a ready-made product
The price on the vendor's site is not the whole sum. Here is what usually surfaces after launch.
Paying per seat. Most platforms count operators as well as dialogues. Your team grows, your bill grows, even if the load on the bot has not changed.
Features outside your plan. Analytics, multiple languages, advanced integrations, data export, removing vendor branding — all of these routinely live on a higher tier that turns out to be twice the price you budgeted for.
Working around limitations. The expense nobody plans for: hours of your team's time spent on workarounds. Exporting a report by hand because the one you need does not exist. Duplicating a record in the CRM because the integration is one-way. Explaining to clients why the bot cannot see their order. Over a year this adds up to real money — it simply has no line in the budget.
Vendor lock-in. Dialogue history, settings and the knowledge base live inside the platform. Moving means redoing part of the work, and the longer you stay, the more expensive the exit.
The hidden risks of a custom build
It would be dishonest to list the downsides of only one option. Development has its own weak spots, and you should know them before signing.
Dependence on the contractor. The main risk. If the code and documentation are poor and the team disappears, you are left with a system nobody can maintain. This is solved at the contract stage: the code and access belong to you, documentation is delivered with the project, and the stack is mainstream rather than exotic.
A longer road to the first result. A box works tomorrow; custom works in a month. If money is burning right now, it is sensible to launch something simple in parallel with development rather than wait.
The risk of overbuilding. The classic trap: the client wants to automate everything at once, the budget triples, and half the scenarios go unused afterwards. The cure is simple — launch narrowly, on the most frequent requests, and expand based on data.
Support is a cost line too. Custom is not "build it and forget it": messenger APIs change, models get updated, new scenarios appear. Budget for maintenance from the start, or the system quietly goes stale within a year.
Four myths about custom development
Myth one: it is expensive. Expensive is relative to the alternative. Building an agent with two integrations costs roughly what two or three months of one support manager costs. The question is not whether the sum is large but how many months it takes to return at your volume. For a business with a thousand requests a month that is usually six to twelve months; at ten thousand, a few months.
Myth two: it takes forever. It takes forever when people try to launch everything at once. A first working version covering the most frequent scenarios ships in two or three weeks, and it already removes most of the load. The rest is built out from data, in parallel with live operation. Projects that drag on for half a year almost always suffer not from complexity but from a lack of priorities.
Myth three: only the author can maintain it. True only for bad code. A sound project is handed over with documentation, a clear structure and a mainstream stack — and any competent developer gets into it within days. Put that in the contract and the myth stops being a risk.
Myth four: you need your own dev team. You do not. You need one person on your side who knows your processes and can answer questions about them. Most often that is a department head rather than a technical specialist: in these projects most questions are not about technology but about how your work is actually organised.
What a quote is made of
Transparency helps both sides here, so here is the cost structure of a typical project.
Analysis and knowledge base. Working through your processes, gathering documents, making the price list and terms internally consistent, preparing training material. Often the hardest part because it needs your time — but it is what decides whether the system answers correctly.
Integrations. The most predictably estimated part: cost depends directly on the number of systems and how ready they are to connect. A popular cloud CRM with a documented API is a few days. A homegrown database with no documentation is weeks, and an honest contractor will say so upfront.
Scenarios and limits of authority. Designing how the agent behaves in different situations, including bad ones: the client is unhappy, the data contradicts itself, the needed information is missing. This part is rarely visible in a proposal, yet it is what separates a system that survives contact with reality.
Testing on real conversations. Running the system against your actual correspondence from previous months. A cheap and highly useful stage: it surfaces mistakes before clients see them.
Maintenance. A monthly line: monitoring answer quality, updating the knowledge base, adapting to messenger API changes. Budget for it from the start — a system without maintenance degrades noticeably within a year.
The hybrid: a third option nobody talks about
In practice the most common right answer is not "either/or". A ready platform and your own development combine well once you split the roles.
Pattern one: the box as a channel, custom as the brain. The platform stays as the operator interface and the point where messengers connect — the part there is no sense in writing yourself. The answer logic, knowledge-base work and actions in your systems move into your own service, which talks to the platform via its API.
Pattern two: the box for the simple, custom for the complex. Typical requests are closed by the ready product, while scenarios that need your data and actions are routed to your own agent. The client notices no difference.
Pattern three: custom as an integration layer. You keep the platform entirely but write an integration layer that connects it to your systems in ways the stock connectors cannot.
The hybrid wins because you pay for building only the part where the box genuinely falls short, instead of rewriting from scratch what already works.
What the ceiling looks like in practice
Here is a composite but typical storyline — we see it with minor variations several times a year.
An online store connects an off-the-shelf platform. The first months go well: the bot answers questions about delivery and payment, takes dozens of identical messages off the managers, and the subscription costs less than the office coffee. Everyone is happy.
Then the small things accumulate. Clients increasingly ask not "how does your delivery work" but "where is my order" — and the bot cannot see that, because it has no access to the system. Managers start duplicating answers by hand. A busy season arrives, volume triples, and the dialogue bill grows with it. Marketing asks for a report by request source, and the platform has no such breakdown — so someone exports data and merges it in a spreadsheet.
A year in, the picture is this: the subscription now costs real money, three people spend hours on workarounds, and the bot closes a shrinking share of requests because the most valuable questions need data it cannot reach. Formally the system works. In practice it has stopped solving the problem.
One simple metric helps you catch this in time: the share of requests the system closed completely, with no human involved. If it falls month after month while the bill rises, you are already under the ceiling — even if everything appears to be working.
How to move from ready-made to your own without losses
If you have been on a platform for a year and can feel the ceiling, migration need not be painful. The order of operations is this.
Take your data first. Export the dialogue history and knowledge base while you still have access. It is the most valuable thing you own: real client questions in their own words are the best training material for a new system, and you cannot buy that anywhere.
Work out what is actually used. The analytics show which scenarios genuinely run. Those are what you migrate, not the platform's whole feature list — usually it turns out that about five of thirty capabilities are in real use.
Run in parallel. The new agent takes one channel or one type of request while the old system keeps working. You compare quality on real traffic rather than in a demo.
Switch gradually. Channel by channel, scenario by scenario. Cancel the subscription last — saving a thousand dollars is not worth the risk of leaving clients unsupported for a week.
A checklist before you decide
Seven questions worth closing before signing anything.
- Does the ready-made product integrate with your exact system — and is it two-way or read-only?
- What will the subscription cost if your request volume doubles and the team grows?
- Can you export your data from the platform in a usable format, and does that cost extra?
- Which features are in your plan and which are only on a higher tier?
- If custom — who owns the code, the access and the documentation after the project ends?
- Who maintains the system a year from now, and at what price?
- What happens to requests the system cannot handle — where do they go?
The last question is the most important and the most often skipped. Any automation needs a clear plan for the cases where it did not work.
What to choose: the short answer
Ready-made or custom is a choice driven not by budget but by how closely your processes resemble the average. An off-the-shelf product wins when the task is typical: answering questions, capturing contacts, modest volume and a popular cloud CRM — there a subscription costs less than any build and launches in days. Custom chatbot development becomes justified once you hit one of five ceilings: there is no integration with your system, you need live data, you need to automate a process rather than a conversation, volume has made the subscription pricier than a build, or the bot has become part of your product. Compare the options by total spend over two years rather than a one-off sum against a monthly one, and account for the hidden lines: per-seat pricing, higher tiers, your team's hours spent on workarounds and the cost of leaving the platform. And remember the third option: a hybrid, where the ready platform stays as the channel while your own development takes on the logic and integrations, often gives the best balance of cost and control — you pay to build only the part where the box genuinely falls short.
Not sure which way to lean? We will look at your processes for free and tell you honestly — even if the honest answer is "take the box". Get in touch or see how we build AI sales agent.
