Studio Laravel Package

Product Decisions This Supports

• Build vs. buy for a conversational layer. BotMan Studio is a project scaffold, not a library — you don't composer require it, you composer create-project botman/studio and inherit an opinionated Laravel app already wired to the BotMan core framework. That forces an explicit decision: adopt a PHP-native bot stack end-to-end, or keep messaging as a thin integration layer against a hosted NLU/bot platform.
• Channel strategy / scope of first release. BotMan's driver model abstracts Slack, Telegram, Facebook Messenger, Twilio, Nexmo, and web widgets behind one intent API (hears(), conversations(), ->reply()). The scaffold ships the config and driver stubs, so a PM can realistically demo "same intent logic, three channels" in a spike rather than committing to one vendor's SDK.
• Time-to-first-demo for stakeholder validation. The packaged botman:install / intent-generation artisan commands and pre-registered service provider collapse days of plumbing into hours. This buys cheap evidence for a roadmap bet — does anyone actually use the conversational flow we're imagining? — before funding a real build.
• Scripted flow vs. NLU investment. The intent-tree pattern this package enshrines is a strong forcing function for the question "do we need machine-learned intent classification at all, or is a decision tree plus a fallback good enough?" Most internal-tool and FAQ bots resolve here, which materially changes the cost of the roadmap item.
• Prioritization of channel parity work. Because drivers are swappable, per-channel effort becomes estimable and separable — useful for sequencing "Slack first, Teams later" rather than treating omnichannel as one monolithic epic.
• Prototype disposal cost. Framing this as a throwaway artifact (a spike repo) rather than a platform commitment is itself a product decision worth making explicitly and early.

When to Consider This Package

Consider it when:

• You need a time-boxed proof of concept or internal tool (ops bot, standup bot, FAQ bot behind a firewall) where the cost of a rewrite in 6–12 months is acceptable and expected.
• Your team is PHP/Laravel-first and the alternative is standing up Node or Python services plus a new deployment pipeline for one feature.
• You require self-hosted, no external SaaS dependency for the conversational logic — no third-party NLU round-trip, no per-message vendor pricing.
• You're on, or can tolerate, a legacy Laravel 5.x / PHP 7.x baseline, and the surrounding app is already pinned there.
• The bot is internally facing or low-blast-radius — misclassification costs an annoyance, not a compliance incident.

Look elsewhere when:

• The bot is customer-facing, revenue-bearing, or regulated. A last release of October 2018 means no security patches, no PHP 8+ guarantees, no Laravel 9/10/11 upgrade path, and a dependency tree that will fight your Composer audit. This is disqualifying for anything with a multi-year lifecycle.
• You need audit trails, PII handling guarantees, or vendor SLAs — there's no active maintainer to contract with. Note the package's own quality signal: 332 stars and a stale release cadence place it in "reference architecture," not "supported dependency."
• Your roadmap includes LLM/agentic capability. Intent-tree frameworks predate function-calling and retrieval; you'll get more leverage from a thin Laravel webhook controller plus a model provider than from a 2018 conversation DSL.
• You need active channel maintenance — messaging platform APIs (Messenger, Slack) churn; stale drivers silently break.
• Modern equivalents fit better: BotMan core itself (verify its maintenance status independently — the studio scaffold lags the core), hosted options like Dialogflow / Twilio Studio / Microsoft Bot Framework, open-source Rasa or Botpress, or simply Laravel HTTP + provider webhooks.

How to Pitch It (Stakeholders)

For executives: This is a low-cost spike enabler, not a platform bet. It's a pre-assembled Laravel + BotMan starter that lets one engineer show a working multi-channel bot in a week instead of a month, which is exactly the evidence we need to decide whether a conversational interface deserves roadmap funding. The trade-off is explicit: the package's last release was October 2018, so anything we build on it is a prototype we intend to throw away. Treat approval as "fund a two-week evaluation," not "adopt a dependency." Success criteria should be defined up front: validated user demand for the flow, a measured intent-comprehension rate, and a documented build-vs-buy recommendation for the production path.

For engineering: Use this as a disposable scaffold or reference implementation, never as a production foundation. Adopt it inside an isolated spike repo with a pinned lockfile and no path to the main application. Extract what's valuable — the driver abstraction, the intent/conversation structure, the webhook handling shape — and reimplement on a current Laravel baseline with a maintained bot integration or a thin custom webhook layer. Flag the risks in writing before anyone starts: unpatched dependencies, no PHP 8 / modern Laravel support, dead channel drivers, and Composer audit noise that will spread if this code ever merges. Budget the rewrite as a known cost of the spike, not a surprise downstream.