Lambo Laravel Package

Product Decisions This Supports

• Framing the build-vs-adopt question for internal scaffolding. Lambo is the cheapest possible "buy" in a build-vs-adopt debate: MIT-licensed, globally installed, zero production footprint, and never referenced from composer.json. A PM can put it on the table as a concrete benchmark — "does an internal golden-path scaffold earn its keep over laravel new plus a 50-line script?" — instead of arguing about scaffolding in the abstract.
• Writing the requirements doc for a "golden path" project template. Whether or not Lambo is adopted, its step list is a ready-made spec for the bootstrap ritual your team actually wants: create the app, create the database, wire .env, link/secure a local host, git init + first commit, run migrations, install Node deps, open editor and browser. Treat that list as the acceptance criteria for whatever you own internally.
• Making onboarding measurable. Time-to-first-commit shows up in new-hire surveys and retros. Lambo is a low-cost lever to test against that baseline — and the result tells you where onboarding friction really lives (tooling vs. access vs. docs). Use it as an experiment, not a strategy.
• A "reference, not investment" call, with the evidence recorded. Archived upstream, last release 2023-08-08, opportunity score 2.65, and differentiators that the framework installer has since absorbed (starter-kit prompts, testing framework, database setup, git init). That combination justifies citing it in a design doc while keeping it off the roadmap — and writing down why a popular-looking tool was declined saves the next PM from re-running the same evaluation.
• Vendor-risk triage with a clean answer. Zero dependents is expected for a globally installed CLI, not a health signal. Because it never enters a shipped product's dependency graph, it carries no customer-facing risk and no customer-facing upside. When a stakeholder asks "what happens if this disappears?", the answer is "nothing that ships" — and exit cost is effectively zero today. Keep it that way.
• Bounded bets on demo, spike, workshop, and client-kickoff velocity. For a date-driven activity where the goal is a running, browser-openable, git-tracked Laravel app in under a minute on a Valet machine, this is a legitimate fit. That is a very different decision from a platform standard, and the PM should say so explicitly.

When to Consider This Package

Consider it only when all of the following hold:

• The team is macOS-based and standardized on Laravel Valet, on the PHP/Laravel versions the August 2023 release actually supports — realistically the Laravel 10 era.
• The composite behavior (host-level database creation, valet link/secure/open, editor and browser launch, git init) measurably beats today's laravel new, which already prompts for starter kit, testing framework, and database setup.
• Usage is individual, opt-in, and pinned (tightenco/lambo:3.1.1) — a convenience on a developer's machine, never a project dependency, never a CI step, never a container build.
• You want to read or fork Lambo's command composition as a design reference before writing an internal bin/new-project script or a Laravel installer --using package.

Look elsewhere — and in practice, assume you will — when any of these are true:

• Archived status is disqualifying for your org. No security response, no issue triage, no compatibility work as Laravel skeletons evolve. For a tool that shells out to local MySQL and Valet, "no maintainer" is a real caveat even for dev tooling.
• You need cross-platform parity. Linux, Windows, WSL, and container-first teams get little here. It's Valet-shaped: redundant for Herd users and actively wrong for Sail/devcontainer users, since it does host-level database creation and hostname linking.
• A dependency-review or security process requires an actively maintained upstream.
• The framework default already covers you — preset prompts, git initialization, and a supported --using extension point upstream make the lower-risk choice the lower-effort one.
• You need reproducibility or CI. Interactive prompts hang forever in non-TTY contexts (CI runners, Docker builds, ssh without -t), and the tool is a local convenience, not environment setup.
• You intend to mandate it team-wide. A mandate implies an internal owner and a compatibility commitment, which is disproportionate to the value. At three developers it's a convenience; at thirty it's an unowned shared dependency with divergent per-developer aliases in home directories and no telemetry.

How to Pitch It (Stakeholders)

To executives: Lambo is a free, MIT-licensed developer-experience utility that collapses the "nothing to running Laravel app" ritual — create the project and database, link the local site, initialize git with a first commit, run migrations, open the editor and browser — into one interactive command, with prompts for auth, frontend framework, and test framework plus reusable presets. It is a small efficiency win for engineering, not a product capability. It never ships in our code and has zero dependents, so customer-facing risk is nil. The decisive caveat: the project is archived, with no release since August 2023, and the framework's own installer has since absorbed most of what made it distinctive. Recommendation: do not adopt as a team standard and do not put it in required onboarding docs; permit it as a pinned, individual convenience for Valet users, and spend a small bounded effort reproducing its useful steps in something we own and version.

To engineering: If you're on macOS with Valet and an older Laravel, this is a genuinely pleasant shortcut — one command, and you get a database, a linked .test host, a git repo with a commit, and your editor open. Configure it once with lambo edit, save project types as aliases (lambo new acme --alias=client), and that's the whole surface area: new, edit, list. If you're on anything newer, or on Linux, Windows, or containers, skip it and use the framework installer, Herd, or Sail. Either way, don't make it a required tool — it shells out to the global laravel binary and will silently drift from current skeletons, and the failure modes are annoying rather than obvious (quiet database-creation failures, repeated-run database and Valet-link collisions, editor launch no-op when EDITOR is unset, nested git init in a non-empty parent). Keep any recipe that matters in a checked-in bin/new script with explicit flags so the invocation is reviewable and the tool is swappable. The durable outcome here is not adopting Lambo — it's borrowing its command composition for a short internal script or a laravel new --using package that we version, test, and own: the same standardization benefit, with a changelog and a compatibility story.