Product Decisions This Supports
- Channel sequencing / "which surface first." This driver lets a BotMan conversation be exposed as a plain HTTP/JSON endpoint, so a web widget, embedded panel, or mobile webview can be the first channel without locking conversation logic to it. Because channels are drivers in BotMan, the decision "web first, Slack/Teams later" becomes reversible rather than architectural.
- Build vs. buy for the chat backend. The honest framing: the real buy decision is BotMan core. This package is a thin adapter — the "build" alternative is roughly a Laravel controller that maps a request into a BotMan message and returns JSON. That makes this a low-stakes, low-cost decision worth making quickly rather than a platform commitment.
- API contract / architecture shape. Using it forces an explicit decision that the assistant is a stateless, decoupled service consumed by one or more frontends (SPA, mobile, kiosk, internal admin tool) rather than server-rendered. One endpoint, many surfaces — useful for consolidation decisions.
- Prototype and concierge validation. Cheap way to put a conversational flow in front of real users to validate intent coverage and copy before committing roadmap to NLU, LLM, or agent infrastructure.
- Scope-setting via maintenance signal. Last release 2018-03-27 is itself a decision input: it points toward experiments and internal tooling, not a customer-critical platform — which shapes how much roadmap you attach to it.
When to Consider This Package
Consider it when:
- You're on Laravel/PHP and either already run BotMan 2.x or are willing to pin it.
- You need a request/response JSON endpoint for a JavaScript widget or a custom frontend — not a native SDK channel.
- The surface is internal, demo, POC, or hackathon-scale, with bounded blast radius.
- Your horizon is short (under ~6–12 months) or you're prepared to fork/vendor the driver.
- The team would rather not write boilerplate and accepts dependency-hygiene trade-offs.
Look elsewhere when:
- The surface is customer-facing, SLA-bound, or security-reviewed.
- You need streaming tokens, WebSockets, or rich presence — this is fundamentally request/response.
- LLM/agent orchestration (tool calling, memory, RAG) is the core value; BotMan predates that pattern, and modern Laravel AI SDKs or a thin custom controller fit better.
- You require PHP 8.2+/8.3+ support, or policy forbids dependencies with no release in 24+ months.
- You need active CVE response.
Verify BotMan core's release cadence before committing — driver staleness here almost certainly mirrors the framework's own lifecycle.
How to Pitch It (Stakeholders)
Executives: MIT-licensed, zero cost, no vendor lock-in. It's a channel adapter, not a platform bet — it gets a chat surface in front of users in days and, more importantly, keeps conversation logic independent of the channel, so we can move to Slack, Teams, or mobile without a rewrite. The trade-off to state plainly: no release since 2018. Recommend approving it for a bounded pilot or internal tool, with a small containment budget (fork, or replace with an in-house controller — roughly a sprint) if it graduates to customer-facing. Not a platform standard.
Engineering: Thin driver on BotMan 2.x — registers a route, translates an inbound HTTP request into a BotMan message, returns the reply as JSON. Small surface area, easy to read, easy to vendor. Risks are dependency drift (PHP version support, unmaintained upstream) and the request/response model (no streaming). Mitigations: pin versions, wrap the endpoint in our own route/controller so the driver is swappable, and write a contract test on the JSON shape so a replacement is drop-in.