Studio Laravel Package

Product Decisions This Supports

• Build vs. buy for back-office/admin tooling. When a roadmap item requires an internal console, ops surface, or CRUD-heavy admin layer, orchestra/studio sits on the "build, but start from a generated skeleton" branch of the decision tree. It gives you a costed middle option between hand-rolling modules from scratch and licensing Nova/Filament-style tooling — useful when the analysis is stuck at "custom is too slow, commercial is too expensive."

• Roadmap sequencing for an extension/plugin ecosystem. If the strategy includes partner modules, customer-authored add-ons, or third-party integrations, Studio's generated conventions become the de facto SDK shape and onboarding contract. That makes this a gating decision for ecosystem investment, not a tooling footnote: you cannot credibly pitch "build on our platform" without a documented scaffolding path.

• Ratifying engineering conventions as a product constraint. Generated code is a PM-visible artifact — it encodes naming, directory layout, namespace casing, and provider registration. Adopting Studio is a deliberate choice to enforce uniformity. That lowers review churn and onboarding time per module; it becomes a liability the moment the org wants bespoke architecture. Frame it explicitly as a convention decision so it doesn't get relitigated module by module.

• Throughput forecasting for internal-tooling quarters. Studio compresses the "first working slice" of a module — extension, migration, model, controller, views — while adding zero runtime capability. Use it to model capacity on repetitive work (how many admin surfaces per sprint), not as a feature to put on a roadmap. It should never be scoped as a user-facing deliverable.

• Dependency-risk classification and support-tiering. A near-zero package score, zero stars, zero dependents, and no advisories means this belongs in the "vendored internal productivity tooling with a named owner" bucket — not the "vetted third-party dependency" bucket. That classification drives procurement, security review, and on-call expectations, and it should be ratified once rather than re-argued.

• An explicit exit criterion. Because the generator is one-shot (generate → review diff → hand-edit; regeneration overwrites), the PM-level decision to keep it needs a review cadence: if engineers hand-rewrite more than half of what it emits, the generator has stopped paying rent and the decision flips to fork-the-stubs or replace with artisan make:* plus house overlays.

When to Consider This Package

Consider it only when all of the following hold:

1. Orchestra Platform is already a strategic commitment (or under an explicit, time-boxed evaluation). Studio has no standalone surface area — its value is coupled to Orchestra's extension manager and ACL. Installed on plain Laravel it generates files referencing providers and menus that don't exist; the classic symptom is an empty admin menu, which is not a bug but a missing prerequisite.
2. The dominant roadmap cost is repetitive boilerplate — extensions, CRUD modules, migrations, wiring — rather than differentiated domain logic.
3. Conventions over flexibility is acceptable. The org wants uniformity and will standardize through stub overlays rather than post-editing every generation.
4. You are prepared to own the upkeep. Exact version pinning across Studio → Orchestra → Laravel, a committed compatibility matrix, published-and-committed config, and a generator regression check before any Laravel upgrade.
5. A named internal owner exists, with a documented fallback path so delivery doesn't stall if the package breaks.

Look elsewhere when:

• Maturity signals matter. Zero stars, zero dependents, no advisories, no community answers, no bus-factor relief. For customer-facing or compliance-scoped work, treat it as unsupported software.
• You're greenfield on mainstream Laravel. Filament, Nova, or Blueprint plus stub overlays cover adjacent ground with active maintenance and a hiring pool.
• You need long-term support. Generated code is yours forever; the templates will drift from Laravel/Orchestra releases and nobody upstream is obliged to fix that.
• The team lacks Orchestra familiarity. Productivity evaporates if engineers must learn the platform and the generator simultaneously.
• You expect a runtime dependency or live synchronizer. It is a one-shot code generator; regeneration is not idempotent and does not preserve hand edits.

How to Pitch It (Stakeholders)

For executives. This is developer-productivity tooling, not a product feature. It reduces the labor cost of standing up admin and back-office functionality by generating repetitive scaffolding — extensions, migrations, controllers, screens — instead of hand-writing it. The strategic upside is optionality: if we pursue a partner or plugin ecosystem, this helps define the onboarding path and lowers the barrier for third parties. The strategic risk is concentration: it lives in a narrow, low-adoption ecosystem with no stars, no dependents, no advisories, and no support contract. Recommended posture: classify it as vendored internal tooling with a named owner, run a time-boxed pilot on an internal-only surface, and pre-agree the exit — fork-and-own, or replace with artisan make:* plus our own stubs.

For engineering. Studio is a require-dev code generator for Orchestra Platform; nothing it produces is a runtime dependency, and nothing it does should ship unedited. The value is a standard, repeatable first slice of a module and a single documented path (scripts/scaffold.sh) rather than memorized flags. The obligations are equally concrete: exact version pins across Studio/Orchestra/Laravel, published and committed config, stub overlays for anything we fix more than once, a review-every-diff workflow with explicit "generator output" commits, and immediate hardening of what it emits — authorization wired to Orchestra's ACL, validation moved into FormRequests, $guarded = [] replaced with explicit $fillable, and a smoke test plus factory per resource. Generated code carries no coverage by default; we own it the moment it's committed. Before any Laravel upgrade, run the throwaway-extension regression and diff against known-good output.

The ask. Approve a two-to-four week pilot scoped to one internal admin surface with pre-agreed metrics: modules scaffolded per engineer-week, percentage of generated lines surviving to merge, and post-generation defect rate. Success means continue with a named owner and a quarterly scope check; failure means we already have the fallback documented and lose only the pilot.