Mise Laravel Package

Product Decisions This Supports

• Build vs. buy for internal scaffolding. tightenco/mise reframes "our standard Laravel starting point" as a versioned, installable artifact instead of a wiki page or a senior engineer's muscle memory. That makes the build-vs-buy question concrete: do we maintain a bespoke scaffolding tool, adopt this recipe runner, or keep documenting manual steps?
• Golden-path / paved-road strategy. If your roadmap includes an internal developer platform or "new service in under an hour" OKR, recipes are a low-cost wedge. Each recipe can encode one convention (auth wired up, Pint + PHPStan + CI config, base models, observability hooks), so the paved road ships incrementally rather than as a big-bang template repo.
• Onboarding cost as a tracked metric. Recipes convert tribal setup knowledge into executable steps, which gives you a measurable before/after: time-to-first-deploy for a new engineer or a new repo. That is a defensible input to headcount and platform investment arguments.
• Standardization vs. team autonomy trade-off. Deciding which recipes are mandatory (security, CI, logging) versus opt-in (auth flavor, queue driver) is a product decision about how opinionated the platform should be. This tool makes that policy explicit and enforceable at install time.
• Multi-project portfolio hygiene. For agencies or teams running many small Laravel apps, recipes reduce drift across repos, which lowers the long-term maintenance tax of a fragmented codebase portfolio.
• Roadmap sequencing. Because recipes are composable, you can ship the highest-pain convention first and validate adoption before committing to a larger template or platform build.

When to Consider This Package

Consider it when most of the following hold:

• You run multiple Laravel applications and repeatedly perform the same post-laravel new setup by hand.
• You have written conventions — or a strong desire to create them — that are stable enough to codify.
• You have engineering capacity to own the recipes as internal code: review, version, and update them, since the recipes are your artifact, not the package's.
• You accept an early-stage, low-adoption dependency (this package shows minimal downstream usage) on a critical path, and can vendor, fork, or replace it if it stalls.
• Your team is already comfortable with Laravel's Artisan and package conventions, so the abstraction is legible rather than magic.

Look elsewhere when:

• You need a single canonical starter kit rather than composable recipes — Laravel's own starter kits and Jetstream/Breeze cover that with more community support and a clearer upgrade story.
• Your stack is polyglot or non-Laravel; the value is concentrated in Laravel idioms.
• You only have one or two apps; the recipe-authoring overhead exceeds the savings.
• You need vendor-backed SLAs, security review, or long-term support for a tool on the critical onboarding path.
• The real problem is environment reproducibility (containers, devcontainers, Nix) rather than file scaffolding — this package does not solve that.

How to Pitch It (Stakeholders)

For executives: This is a small, cheap experiment in reducing the time it takes to stand up a new Laravel service and get a new engineer productive. It lets us encode our standards once and apply them consistently, rather than relying on documentation that decays. Cost is a timeboxed spike and some ongoing ownership of our own recipe definitions; the package itself is a thin runner, so the risk is low and the exit is easy. Success looks like a measurable drop in setup time and fewer "works on my machine" setup deviations across repos. Recommendation: fund a two-week evaluation on one real repo before any broader commitment.

For engineering: Mise runs installable recipes that scaffold files and execute setup steps in a Laravel app. It gives us a place to put the setup we keep redoing — CI config, static analysis, base auth, logging conventions — as versioned, reviewable code. Two caveats to be honest about: the package has very little downstream usage today, so we should pin a version, read the source, and be prepared to vendor it; and the recipes become ours to maintain, which is real ongoing work, not a one-time install. Ask: pick two candidate recipes that hurt most today and prototype them in a branch.