Botpress vs. a custom AI build, at a glance
| Category | Botpress | Custom AI build |
|---|---|---|
| Best at | Conversational flows built visually, with room to extend through code | Conversation plus everything around it — workflows, judgment calls, systems with no connector |
| Setup | Self-hosted or vendor-hosted, configured by someone who can read the studio and its scripting layer | Scoped first, then built — priced clearly before work starts |
| Data control | Can be strong when self-hosted; the specifics depend on deployment choice and current product terms you should confirm directly with Botpress | Strong — built and deployed inside your environment or ours, by agreement |
| Licensing and hosting | Open-source-rooted, with both self-hosted and vendor-hosted paths on offer; verify the current licensing terms and plan structure yourself before you architect around them | Scoped and quoted upfront; the price doesn't reshape itself as usage grows |
| Extending it | Developer-friendly hooks and custom actions for adding real logic around the visual flow | Code throughout — the whole system, not a flow with extension points bolted on |
| Conversation design at scale | Handles a defined set of intents and flows well; complexity climbs fast once the tree branches into dozens of edge cases | Conversation logic designed, structured, and tested the way any other part of the system is |
| The long tail of real input | Depends heavily on how much of the unexpected phrasing, typos, and off-topic detours got mapped ahead of time | Built and evaluated against your actual transcripts, so the tail gets designed for, not discovered in production |
| Systems with no connector | Community and official integrations cover common tools; an unusual system may still need custom work either way | Built directly against whatever your business runs, connector or not |
| Testing and evaluation | Possible, but the discipline of running structured evals against real transcripts has to be added deliberately | Standard practice — the system is evaluated against your own conversations before and after launch |
| Who runs the infrastructure | You, if self-hosted — hosting, upgrades, and scaling become your team's job | Your team, or an ongoing arrangement with us, by agreement |
The table lands closer together than most comparisons on this page, and that's deliberate — Botpress narrows the distance to a custom build more than a fully-hosted, no-code chatbot widget ever does. But the real decision here isn't a feature checklist, because most of what separates the two doesn't show up as a missing button. It shows up in how well the conversation holds together once real customers start typing things you didn't plan for.
When Botpress is genuinely the right choice
- You already have someone who can own the studio and its scripting layer. Botpress rewards a team with a developer or a technically fluent operator willing to build flows, extend them with code where needed, and maintain the deployment over time.
- The conversation is a defined, bounded job. A guided FAQ bot, a structured intake flow, a simple booking or triage conversation with a small number of paths — these are exactly the shape Botpress's visual studio is built for, and building them from scratch would be solving a problem that's already solved.
- Self-hosting or a source-available model matters to you. If keeping the platform on infrastructure you control, or being able to inspect what's actually running, is a real requirement rather than a preference, Botpress's open-source roots are a genuine advantage over a fully closed hosted competitor — confirm the current licensing model directly with Botpress before you commit to it, since terms and editions change.
- You want to prototype a conversation fast and extend the one part that needs real logic. Sketching flows visually, then dropping into code for the step that needs actual reasoning, is a legitimate way to move quickly without commissioning a full build for every idea.
- Avoiding a fully proprietary, closed platform matters on principle. A developer-friendly, partly open architecture means a team isn't purely at the mercy of one vendor's roadmap in the way a fully closed no-code competitor would leave them.
We'll say this plainly: Calfy sometimes points a team toward Botpress directly, when the conversation is genuinely bounded and someone on the team is ready to own the studio. It's also common for a Calfy build to use a platform like Botpress for the conversational surface while custom code handles the parts around it — the AI agent logic making decisions, the integrations with systems that have no connector, and the evaluation harness that checks the bot against real transcripts. This isn't a page written to talk a team out of a tool we sometimes recommend or build alongside.
Where Botpress hits its ceiling
Botpress doesn't get worse as a bot grows — self-hosted or not, the studio stays exactly as capable as it was on day one. What changes is how much of the real work moves outside it.
Conversation design gets harder to hold together as it scales, not easier. A handful of intents and flows is straightforward to lay out visually. A few dozen, each with branches for follow-up questions, corrections, and topic changes, turns into a tree that's genuinely difficult to reason about on a canvas — the same complexity a codebase absorbs more gracefully once it's structured as code rather than as connected visual nodes.
The long tail of what people actually say is where bots quietly fail. Real customers don't stay inside the flows you mapped. They ask follow-up questions out of order, mention something unrelated mid-conversation, or phrase a normal request in a way nobody anticipated. Whether Botpress handles that gracefully depends entirely on how much of that tail got designed for in advance — the platform doesn't discover it for you.
Integrating with a system that has no connector is still a build problem. Botpress covers the common tools well, but the moment your business runs something unusual — a legacy database, an internal tool, a vendor with no public API — you're writing custom integration work regardless of which platform sits in front of it. At that point the platform is no longer the thing saving you time.
Evaluating against real transcripts has to be added, not assumed. Knowing whether a bot is actually working means running it against the messy, real conversations your business has already had — not a handful of demo scripts — and checking where it misreads intent or answers confidently wrong. That discipline exists in most serious deployments, but it's work a team layers on deliberately; it isn't something the studio hands you by default.
You are still operating what you host. Choosing the self-hosted path means your team owns uptime, upgrades, and security patching for the instance itself, on top of maintaining the flows running inside it — real, ongoing work that a fully managed build would carry differently.
The person who built the flow tree is a single point of failure. A large Botpress deployment — many intents, several with custom code attached, branching in ways that made sense to whoever built them at the time — is genuinely hard for someone else to pick up months later, the same risk any single-owner system carries.
When a custom build wins
A custom build earns the extra step of a proper scoping conversation exactly where Botpress stops closing the gap: when the conversation isn't a bounded set of flows but an open-ended one that has to hold up against real, messy input; when the business needs the logic evaluated against its own transcripts rather than a demo; when the process reaches into systems with no connector and no shortcut around writing the integration; or when nobody on the team wants running infrastructure and flow-tree maintenance to become an ongoing job. It also buys something the table above can't fully capture — conversation logic engineered the way the rest of your software already is, instead of a visual tree doing its best impression of one. Our build vs. buy guide walks through that trade-off in more general terms, and it's worth reading alongside our comparison against Voiceflow if you're weighing more than one conversational platform at once — the two solve a similar shape of problem with different trade-offs.
Where the two meet
This doesn't have to be a clean either/or. A team can run Botpress for the bounded, well-mapped part of a conversation — the FAQ layer, the intake questions, the routing — while custom code carries the parts that need real judgment, an audit trail, or a connection into a system with no API. That split is common, and it's often the most honest answer for a team that already has someone comfortable maintaining a Botpress deployment. See the broader range of AI agent work we do either way, including builds where a platform like Botpress is the right component for part of the system rather than a consolation prize.