Laravel Starter Kits: Past, Present and Future

Povilas Korop runs Laravel Daily and has published his own starter kit (laraveldaily/starter-kit). He regularly covers starter kit topics on his YouTube channel.

Teams starter kit

Teams support was added to all four official Laravel starter kits (React, Vue, Svelte, Livewire) on 27 March 2026. It was a missing feature since the new starter kits replaced Jetstream in Laravel 12.

How it works:

Enabled at project creation time via a prompt in the Laravel installer (requires installer 5.25.0+)
Each user is assigned a personal team on registration
Teams use URL-based context (/{current_team}/dashboard) rather than the session-based approach Jetstream used, which means a user can operate two team contexts in separate browser tabs simultaneously
Built-in screens for creating, switching between, inviting members to, and managing teams
Route parameters handle access control automatically with no additional middleware or policies needed for basic team membership checks
Reserved names (e.g. settings, login, dashboard) are blocked as team names to prevent route conflicts

References:

Custom internal starter kit

Laravel supports community starter kits via the --using flag in the Laravel installer:

laravel new my-app --using=vendor/your-starter-kit-name

The kit needs to be a valid Composer package on Packagist with a composer.json and .env.example. Any post-installation steps go in the post-create-project-cmd array in composer.json.

All code lands directly in the new application at creation time. There is no ongoing package dependency and no update mechanism. The kit is a one-time scaffold, not something that pushes changes into existing projects.

Povilas has done this himself with laraveldaily/starter-kit, a Blade-only kit built to avoid the overhead of Livewire/React/Vue in tutorial demos. Worth reading through as a reference for structure.

The Laravel team internally manages 21 variants across 8 repositories using a tool called Maestro, a layered build system where changes are made in built output and synced back to source layers. Referenced here as context for how multi-variant kit maintenance scales.

References:

Maintenance concerns with a custom starter kit

Because code is copied directly into the application at creation time, there is no update mechanism. If the starter kit is updated later, existing projects do not receive those changes. Each new project gets the current state of the kit at the point it was created.

This removes the version compatibility problem, but linting rules, test scaffolding, and structural patterns defined in the kit will diverge across projects over time as each evolves independently.

Povilas noted in a comment on the Laravel Daily site that the commercial starter kit market is under pressure because developers are increasingly using AI to generate custom boilerplate per project. That context is relevant when deciding how much investment to put into a shared kit.

The Maestro article is a useful reference for understanding how the maintenance problem compounds when multiple variants need to stay in sync.

Privato.pub - private Composer package registry

Privato.pub is a hosted private Composer registry. It handles:

Private package hosting with full Composer compatibility
Per-customer licence key access
GitHub repository sync via webhooks
Stripe integration for subscriptions or one-time payments
Branded pages with docs, changelogs, and downloads
Download tracking

Relevant for distributing in-house Laravel packages across projects without publishing to Packagist. Alternatives include Private Packagist (the official paid option from the Composer team), self-hosted options like Packistry (a self-hosted Composer repo built with Laravel), or a private GitHub/GitLab repository referenced directly in composer.json.

References:

Notes from Laravel Live UK 2026.