Botman Laravel Starter Laravel Package

Product Decisions This Supports

• Feasibility spikes before roadmap commitment. This is a working Laravel app with BotMan pre-wired — composer create-project, edit routes/botman.php, talk to the bot. A functioning conversational surface exists in an afternoon. The deliverable is evidence ("is a bot a viable surface for this problem, and what does one cost us?"), not code you intend to keep. Spend two engineering weeks here before you spend a quarter on a committed bot initiative.
• Channel strategy, decided on observed behavior. BotMan abstracts Web, Slack, Telegram, Facebook Messenger, and more (Twilio/Nexmo for WhatsApp) behind one conversation flow, and the bundled web driver means the first demo needs no channel credentials at all. That lets you exercise a flow across surfaces and pick a launch channel from what you saw rather than from intuition — and it defers procurement/integration conversations until the concept is validated.
• Build vs. buy, with the "build" column actually populated. Vendor chatbot platforms (Dialogflow, Intercom, Zendesk bots) are easy to price in a vacuum and hard to compare. This gives you hours-to-first-working-flow and a real maintenance estimate as a baseline, which materially improves your negotiating position and the honesty of the comparison.
• Internal and low-stakes tooling. HR FAQ, IT helpdesk triage, onboarding checklists — deterministic flows where the polish, uptime, and compliance bar sits well below customer-facing products.
• Reference architecture, valuable even if nothing ships. The intent routing, middleware pipeline, conversation classes, and driver structure are a concrete model for how a bot fits inside a Laravel codebase. That model shapes how you scope and estimate engineering work later, regardless of whether this artifact survives.
• Explicitly not a fit for: NLU-heavy assistants, multi-turn transactional flows (payments, bookings), compliance-bound domains (health, finance, PII at scale), anything internet-facing on the critical path, or any roadmap item with an SLA attached.

When to Consider This Package

Consider it when:

• The team is already Laravel/PHP and you want a prototype this sprint, not a platform decision this quarter.
• The flow is largely deterministic — menus, FAQs, commands, guided form-fill.
• The audience is internal, or the demo exists for stakeholder validation rather than customer use.
• You are willing to fork it and own the code, because upstream will not. No release since October 2018, zero tracked dependents, no security patching, no support.

Look elsewhere when:

• Maintenance risk is disqualifying. Seven years without a release means expect Composer friction on PHP 8.1+, Laravel 9/10/11, and Symfony 6+, plus driver SDKs that have drifted from current channel APIs. Validate early with composer why-not and treat incompatibility as a go/no-go gate, not a porting project.
• You are treating it as a dependency. Critical framing: it's a starter skeleton, not a library. You scaffold a disposable app from it; you do not composer require it into an existing product. That's a governance and upgrade-path decision, not a vendor evaluation.
• You need production requirements: SLA, observability, audit logging, PII handling, rate limiting, on-call rotation, defined vulnerability response.
• You need genuine language understanding. Use BotMan core with an NLU driver, or an LLM-based approach — don't inherit an aging shell around it.
• The webhook is internet-facing on anything that matters. An unpatched skeleton on the critical path is a security and compliance question, not a maintenance one. It can also block routine Laravel security patching elsewhere if it isn't isolated.

Practical recommendation: scope it as a one-to-two-week spike asset in an isolated, version-pinned container with a written exit trigger agreed up front. Keep routes/botman.php thin and push logic into handler and Conversation classes, with cross-cutting concerns as middleware — that makes the portable asset business logic rather than framework glue. If the spike graduates, rebuild the shell on current Laravel plus BotMan core and port only handlers, intents, and middleware. Document what you'd reuse before writing a line, so the exit cost stays visible.

How to Pitch It (Stakeholders)

For executives: "This is a free, open-source starting kit that stands up a working chatbot prototype in days instead of weeks — across web, Slack, Telegram, and WhatsApp. It hasn't been maintained since 2018, so I am not proposing it as a production dependency and there is no committed spend. The deliverable is a validated conversation design, a channel recommendation, and a real cost estimate for the production build — plus a benchmark to hold vendor chatbot quotes against. It turns a speculative roadmap line into evidence: a demo stakeholders can talk to, and an estimate grounded in something we actually ran."

For engineering: "It's a Laravel skeleton with BotMan already wired — channel drivers, a middleware pipeline, intent routing, Conversation classes for multi-turn flows, and a local chat widget for testing. It removes a few days of boilerplate so we design conversations instead of plumbing webhooks. Caveats, stated plainly: treat it as a throwaway branch. Stale Laravel/Symfony constraints on PHP 8.1+, no releases in seven years, zero dependents, abandoned driver SDKs. Our loop is create-project → edit routes/botman.php → test on the web driver, with no channel credentials until the concept is validated. If we greenlight, we port handlers, intents, and middleware onto current BotMan core and keep the skeleton out of the dependency tree entirely, isolated from business-critical apps."

Why the small bet is worth it: the downside is bounded to a couple of engineering weeks on a disposable branch with no committed spend and a documented exit trigger. The upside is a validated product direction, a better-informed vendor negotiation, and a channel decision made on observed behavior rather than assumption.