Product Decisions This Supports
Greenfield scaffolding decision, not an integration decision. This is a project skeleton, not a runtime dependency — you don't composer require it into an existing app, you clone/fork it and start a repo from it. That reframes every evaluation: the question isn't "does this improve our product," it's "does this standardize how we start new products."
- New service / new product bootstrap. Use it as the default template when standing up a new Laravel application that is expected to live for years and be maintained by more than one engineer. It front-loads the decisions a team usually argues about in month three: static analysis level, formatter, refactor rules, test framework, type coverage enforcement, and AI-agent conventions.
- Build vs. buy vs. borrow. It is effectively "borrow" — you inherit opinionated configuration (
larastan v3, pint, rector v2, pest v5, PHP 8.5, Laravel 13), then own the fork permanently. There is no vendor relationship, no update channel, and no upgrade path from upstream. Budget for that: the initial day of setup is cheap; the ongoing cost is that quality tooling config becomes your code, not a maintained dependency.
- AI-assisted development standardization. The most differentiated asset here is the shipped agent contract —
AGENTS.md, Cursor rules, and Laravel Boost/MCP tool guidance that tell coding agents to run Pint after edits, use search-docs before changing code, prefer Eloquent API Resources, hit database-schema before writing migrations, and never delete tests without approval. If your roadmap includes rolling out AI coding agents across the team, this is a concrete way to make agent output conform to house style instead of negotiating it per engineer. That is a process decision worth more than the skeleton itself.
- Quality-gate policy decisions. Adopting it is an implicit commitment to strictness as a default: max-level static analysis, mandatory tests per change, explicit return types and parameter hints, PHPDoc array shapes. That's a hiring and velocity decision as much as a technical one — it raises the floor on correctness and the bar on onboarding.
- Use cases where it fits cleanly: internal tools and back-office services with small, senior teams; API-first products (the guidance defaults to versioned API Resources); long-lived services where refactor safety matters; teams already standardized on Pest and Nuno-adjacent tooling.
- Use cases where it does not fit: anything with an existing codebase (retrofitting strictness to Larastan max on a legacy app is a multi-quarter project, not an adoption), products needing auth/UI scaffolding out of the box, or teams shipping on an LTS-pinned PHP version.
When to Consider This Package
Adopt when most of the following are true:
- You are starting a new repository, with no legacy code to migrate.
- Your team is comfortable on the bleeding edge: PHP 8.5, Laravel 13, Pest 5, Larastan 3. Verify the exact version matrix against your hosting, CI images, and any third-party packages you depend on before committing — pre-GA ecosystem pins are the single biggest practical risk here.
- You have at least one engineer who owns tooling and can fork, prune, and maintain the config long-term, including security patching (this is a fork, so upstream fixes don't reach you automatically).
- You want strictness enforced from commit one, not aspirational style docs.
- You are standardizing AI agent behavior and want the rules to live in the repo rather than in prompts.
Look elsewhere when:
- You have an existing application. There is no migration story; treat this as a template only.
- You need auth, user management, billing, or a UI kit. This is a deliberately minimal skeleton — pair it with (or choose instead) Breeze/Jetstream/Filament-style scaffolds if you need functional surface area.
- You require vendor support, an SLA, or a security-response commitment. Single-maintainer project, ~880 stars, 0 dependents (structurally expected for a skeleton, but it also means no ecosystem validation and no downstream bug reports doing your QA).
- Your organization pins to LTS releases or has a policy against pre-GA major versions in production.
- Your team is junior-heavy or velocity-constrained. Max-level static analysis plus mandatory tests per change is a real throughput tax in the first quarter. Be honest about whether that trade is worth it — it usually is for a small senior team and usually isn't for a large mixed one.
- You need a stable, long-lived baseline. Because you own the fork, every Laravel/PHP upgrade becomes your work. Confirm someone actually wants that job.
How to Pitch It (Stakeholders)
To executives: "This is a starting template for new Laravel services, not a product we buy. It costs roughly a day of setup and gives us enforced code-quality gates and AI-agent conventions baked in from the first commit — meaning fewer review cycles, less rework, and a consistent codebase across teams. The trade is that we own the template permanently and it runs on very current framework versions, so we should use it for new internal and API services where we control the environment, not for anything on our LTS footprint."
To engineering leadership: "It's an opinionated fork-and-own skeleton: PHP 8.5 / Laravel 13, Larastan at max, Pint + Rector + Pest, strict types, tests required per change, plus AGENTS.md and Cursor/Boost rules that make coding agents follow house conventions instead of inventing them. Highest-value part is the agent contract, not the config. Two caveats to accept up front: there's no upgrade path from upstream, so tooling config becomes our code, and the strictness has a real onboarding cost we should only impose on teams that can absorb it."
To engineering (the ones who'll use it): "Clone it rather than require it. You get the formatting, static analysis, and test enforcement you'd otherwise spend a sprint negotiating, and the agent rules mean less prompt-writing per engineer. Prune what you don't want — delete the rules that don't match how we work — and expect to maintain it yourself, since upstream updates won't flow to us."