Comparisons
Build or buy a company assistant: how to decide
Build or buy a company assistant: what production really needs beyond the prototype, a side-by-side comparison, when each option wins, and questions to ask vendors.
Updated · 6 min read
Why does the prototype make building look easy?
A working demo is a few days of work for one engineer: call a model API, give it two or three functions, wrap it in a chat window. The demo answers questions, fetches a record, drafts an email. It is convincing, and it is genuinely a small fraction of the system you will run in production.
What the demo leaves out is everything that makes it safe to point at real systems and real customers: who is asking, what they may do, which actions need a human signature, how credentials are stored, what happened last Tuesday at 14:05 and why. None of it is intellectually hard. All of it takes time, and none of it can be skipped once the assistant touches email, tickets or phones.
What does a production assistant actually need?
Use this list to size a build honestly. Each line is a component someone must design, build, test, secure and keep running after launch.
- Model access with fallbacks, timeouts, token budgets and cost tracking, and the freedom to switch models.
- Connectors to each business system, with authentication, pagination, rate limits and error handling.
- Credential storage: secrets encrypted at rest, scoped per customer or business unit, rotated, never shown back.
- Identity and roles on every request, checked before any tool runs.
- Per-tool policies: allow, deny or require approval, by tool, assistant and organisation.
- Durable pause and resume, so a run can wait hours for an approval without losing state.
- An audit trail of requests, tool calls, approvals and results that security and compliance can read.
- Organisation or business-unit isolation enforced in the data layer as well as in application code.
- Channels: web chat, API, email, messaging apps such as WhatsApp, Telegram, Microsoft Teams or Slack, and possibly voice and phone, each with its own streaming and failure modes.
- Evaluation and monitoring: regression tests for prompts, review of failed runs, and alerting.
- For the Gulf and Levant: Arabic and English throughout, including right-to-left reports.
Build vs buy compared: the trade-offs side by side
The table is written from the point of view of a company whose core business is not tooling. If the assistant is your product, the weight of several rows changes.
| Criterion | Build in-house | Buy a platform |
|---|---|---|
| Time to a prototype | Days | Hours to days |
| Time to production | Months: security, governance, channels and operations | Weeks: configuration, connectors and review |
| Control over behaviour | Total, down to every prompt and retry | Bounded by what the platform exposes |
| Your internal systems | Anything you can code against | Built-in connectors plus whatever extension points exist, such as MCP |
| Security and governance | Designed, built and audited by your team | Provided; you verify how it works |
| Long-run maintenance | Yours, including provider API changes and model upgrades | Mostly the vendor’s |
| Where data and secrets sit | Wherever you decide | Depends on the vendor’s hosting and deployment options |
| Cost profile | Engineering salaries up front and ongoing | Subscription or usage fees |
| Lock-in risk | Lock-in to your own code and its authors | Lock-in to a vendor unless data and configuration can be exported |
| Skills required | Backend, security, evaluation, operations | An owner who understands the process and the risks |
When should you build in-house?
Building is the right call when the assistant is where you compete, or when constraints rule out every platform you have evaluated. The test is not whether your team can build it, most can, but whether it can carry it for years.
- The assistant is the product itself, or a differentiator customers pay for.
- Regulation or policy requires data and secrets to stay on infrastructure you operate, and no vendor offers a deployment that satisfies it.
- Your workflow needs behaviour no platform exposes, such as custom planning logic or unusual execution guarantees.
- You have a team that will own maintenance, security reviews and on-call after launch, as well as the build.
When should you buy a platform?
Buying wins when the assistant is a means to an end: faster incident triage, a cleaner inbox, fewer repetitive calls. Here the value is in the process you automate, and every month spent rebuilding identity, approvals and audit is a month without that value.
- The engineering team is small or its roadmap is committed elsewhere.
- You need governance on day one: permissions, approvals and an audit trail that security will sign off.
- You want to test whether a use case pays off before committing a build budget.
- You need several channels or several business units working from the same governed setup.
The hybrid path: buy the platform, build the edges
The choice is rarely all or nothing. A common pattern is to buy the governed core, the runtime, policies, approvals, audit and channels, and build only what is specific to you: connectors to in-house systems, domain prompts and evaluation sets.
Open standards make this practical. With the Model Context Protocol, your team can wrap an internal API as an MCP server once and plug it into any compatible platform. In Botify any MCP server can be registered per organisation and its tools join the catalogue under the same policies as the built-in connectors, starting on mandatory approval until an admin reviews them.
The hybrid path also lowers lock-in. Your MCP servers, prompts and test sets are yours and move with you if you change platforms.
Questions to ask any platform vendor
Whichever way you lean, these questions separate a demo from a system you can run. Ask for the mechanism, not the adjective: “secure” and “enterprise-grade” are not answers.
- How are connector credentials stored and encrypted, how are keys rotated, and can the API ever return a secret?
- Can a specific tool be forced to require human approval, per assistant and per organisation?
- Where is organisation isolation enforced, and what stops a query from reading another organisation’s data?
- What exactly is recorded in the audit trail, and can we export it?
- Which models can we use, and can we switch without rebuilding assistants?
- How do we connect a system you do not support: an SDK, a webhook, or an open standard such as MCP?
- How well does it handle Arabic, including dialects in voice and right-to-left documents?
- If we leave, what can we take with us?
Frequently asked questions
How long does it take to build in-house?
A prototype typically takes days. A production system with identity, per-tool permissions, approvals, audit, credential security and monitoring usually takes months, depending on how many systems and channels it touches. Budget as much for operating it after launch as for building it.
What are the main costs of building?
Engineering time for the platform pieces, model usage, hosting, security reviews and ongoing maintenance as model and system APIs change. The platform pieces, not the model calls, are usually the part teams underestimate.
Can we start on a platform and build later?
Yes, and it is a sensible way to reduce risk: you learn what users actually need before committing a build budget. Keep ownership of what is portable, such as prompts, evaluation sets, documents and any MCP servers you write, so they can move with you.
Does buying a platform lock us in?
To some degree, as any system does. Reduce it by preferring platforms that use open standards for tools, let you choose models, and export audit data and configuration. Building also creates lock-in, to your own code and the people who wrote it.
Do we need a machine learning team to deploy an assistant?
Not for most business assistants, which use hosted models rather than training their own. You need a process owner, someone who understands the systems being connected, and someone accountable for permissions and approvals.