Most flow-built chatbots start as a tidy diagram. A greeting, three buttons, a branch for each. Then someone asks about weekend opening, so a fourth button appears. Then a customer asks two things in one message, which the flow cannot handle, so a fallback gets added. Six months later the diagram has ninety boxes and nobody wants to touch it.
That drift is the practical centre of the chatbot builder vs AI assistant decision. Building your own gives you control. It also makes you the permanent owner of every path, every edge case and every update.
There are really three routes, and they suit very different businesses.
The three routes, described plainly
- Flow builders (often no-code): you drag boxes into a decision tree. The bot follows the paths you draw, with buttons or keyword matching. Predictable, but only as broad as your diagram.
- Developer frameworks: code libraries and model APIs your developer assembles into a custom bot. Anything is possible, provided someone builds, hosts and secures it.
- Ready-made assistants: a hosted product you teach with your own material, such as your website, documents, a plain description of the business and question and answer pairs. It answers in natural language from that content and you switch on the actions you want.
Each has real strengths. The differences show up in the first week and, more sharply, in the first year.
Time to a useful first version
| Flow builder | Developer framework | Ready-made assistant | |
|---|---|---|---|
| Skills needed | Patience, logic | Programming, hosting, security | Clear writing about your business |
| Initial setup | Days, mapping paths | Weeks, building and testing | An afternoon to a few days |
| Handles unexpected wording | Poorly | Depends on the build | Well, if content covers it |
| Answers questions you did not map | No | Depends on the build | Yes, from supplied content |
| Where it runs | Vendor's platform | Your own infrastructure | Vendor's platform, embedded by script tag |
| Who fixes it at 9pm | You | Your developer | The vendor for the platform, you for content |
The ready-made route is quickest mainly because you skip the mapping. Instead of drawing every question, you supply the material and test what comes back. What training a chatbot really means today explains that shift in more detail.
Maintenance: where the real cost sits
Setup is a one-off. Maintenance never ends, and it is the part people underestimate when they choose to build.
Here is a worked example with assumed figures you can change. Say your business adds or changes four services, prices or policies a month.
With a flow builder, each change means finding every branch that mentions the old information, editing it and testing the paths around it. If that takes two hours per change, you spend eight hours a month.
With a custom framework build, content changes might be quick, but you also have library updates, model changes, hosting, monitoring and the occasional bug. Assume four hours of developer time a month on top of content work. At whatever your developer charges per hour, that is a recurring bill.
With a ready-made assistant, each change means updating the web page or document, then re-crawling or re-uploading. Call it 20 minutes per change, so roughly an hour and twenty minutes a month, plus a weekly look at the questions it could not answer.
Your numbers will differ. The shape rarely does.
There is also a less visible maintenance cost: finding the problems in the first place. A flow bot fails silently when a visitor types something the diagram did not expect, and you only find out if you read transcripts. A ready-made assistant that records unanswered questions as knowledge gaps hands you the to-do list, which turns maintenance into a short weekly review rather than detective work.
Skills you need on each route
With a flow builder, the skill is conversation design: anticipating what people will ask and how they will phrase it. This is harder than it sounds, and gaps are invisible until a customer falls into one.
With a framework, you need engineering. Beyond getting answers out of a model, someone has to handle grounding so it does not invent facts, data isolation, retention, encryption, rate limits and what happens when the model provider changes something. That is a small product, not a weekend project.
With a ready-made assistant, the skill is mostly writing. Your website and documents need to say clearly what you do, what it costs and what the policies are. If your site is a mess, that is the first job either way; training a chatbot on a messy website is a realistic guide, and the FAQ generator can help draft missing answers.
When building your own is the right call
It would be dishonest to pretend a ready-made product always wins. Building makes sense when:
- The bot must run a complex, multi-step process inside your own systems, such as pulling live account data and changing it.
- You have strict requirements about where data is processed that no hosted product meets.
- You already employ developers with spare capacity and a reason to maintain it.
- The conversation is so narrow and fixed, like a single eligibility check, that a small flow covers it completely.
If none of those apply, you are mostly signing up to maintain software that is not your core business.
What a ready-made assistant will not do
For balance: a hosted assistant gives you less control over the internals. You configure its persona, content and actions, but you are not rewriting how it works. Integrations are limited to what the product supports; with SpideyChat that means a webhook sending JSON to tools like Zapier, Make, a CRM or Slack, plus built-in lead capture, tickets and human handover. The docs explain how each action is set up. If your plans need more than that, the build route may be justified.
Deciding in a week
Write down the ten questions your customers ask most and the one process you would most like automated. Then try the cheap option first: put a ready-made assistant on a test page, try it against your own site, and ask it those ten questions in the way customers actually phrase them.
If it handles the questions and the process only needs a lead or ticket passed onwards, you have your answer without writing a line of code. If the process needs deep access to your own systems, take that list to a developer, and you will be starting the build with a far clearer brief.