Laravel Preset Laravel Package

Product Decisions This Supports

• Starter-kit / golden-path strategy. Whether to standardize how new Laravel services and side projects are bootstrapped (auth scaffolding, frontend stack, linting, CI config) versus letting each team pick its own defaults. A preset like this is the cheapest possible experiment in that direction: it encodes one maintainer's opinions into a single composer require + php artisan preset step.
• Build vs. buy for internal tooling. The realistic choice is rarely "adopt this package" — it's "fork this package's opinions into a 200-line internal skeleton" versus "write that skeleton from scratch." This repo is a useful reference implementation and a conversation starter, not a dependency to plan around.
• Developer-onboarding investment. Presets trade upfront curation for reduced time-to-first-commit and fewer "it works on my machine" support tickets. If onboarding friction is a recurring roadmap complaint, this is one lever to test.
• Standardization vs. team autonomy. Choosing an opinionated preset is a small governance decision: it reduces configuration drift across repos at the cost of constraining teams that want a different frontend or auth approach.
• Not a product-facing feature decision. There is no end-user capability here; it should not appear in customer-facing roadmaps. Its only roadmap relevance is engineering velocity and platform consistency.

When to Consider This Package

Consider it (or, more accurately, consider mining it for ideas) when:

• You are running a Laravel 5.x–6.x era codebase and want a curated default scaffold for new projects or internal packages.
• You have a small team or solo maintainer who can absorb a preset's opinions without a committee, and where consistency matters more than per-project flexibility.
• You want a cheap proof of concept for a "golden path" template before investing engineering time in a bespoke internal starter kit.
• You need a readable reference for how Laravel presets are structured — the MIT license makes copying and adapting straightforward.

Look elsewhere when:

• You are on Laravel 8+. The preset mechanism and default frontend/auth stacks moved on (Breeze, Jetstream, the laravel-frontend-presets ecosystem). A preset last released in March 2019 is very likely incompatible or at least untested against current framework versions.
• You need a maintained dependency. 19 stars and no release in six years is a strong signal of a single-maintainer hobby project; assume no security patches, no framework-version support, no issue triage.
• Compliance, security review, or long-lived platform concerns apply. An unmaintained scaffold that generates auth and build config is exactly the kind of thing that quietly bakes in stale patterns.
• Your team already has a starter kit, or the opinions (frontend framework, auth approach, directory layout) conflict with your platform standards — forking to reconcile the differences usually costs more than writing your own.
• You need guaranteed upgrade paths across Laravel majors; a private, owned skeleton with a small test suite is the safer bet.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed scaffolding tool that lets engineers spin up a new Laravel project with a pre-agreed set of defaults instead of hand-configuring each one. The business case is velocity and consistency — faster onboarding, fewer divergent setups. But be clear about the risk profile: it is a solo-maintainer project with very low adoption and no release since 2019, so we should not take a dependency on it or plan around it. The recommendation is to treat it as a reference design, spend a small amount of engineering time (days, not weeks) extracting the useful conventions into a skeleton we own and can maintain, and revisit only if we standardize Laravel project creation as a platform initiative.

To engineering: Small, readable, MIT-licensed, trivially forkable — but effectively abandoned and pinned to a Laravel generation we no longer target. Don't composer require it into anything production-bound. Do read it as a worked example of preset structure, diff its opinions against our current laravel/laravel skeleton, and use it to shortcut the design of an internal starter kit with a couple of smoke tests and an owner. If anyone wants to trial it, do it in a throwaway repo first and check compatibility against our current Laravel version before it influences a roadmap commitment.