How to Add a Starter Kit to an Existing Laravel Project

Most Laravel starter kits are designed for clean-slate repositories initiated via laravel new. In production, however, developers frequently need to bolt modern authentication, profile management, or full-featured dashboards onto an existing codebase with legacy tables and custom business logic. With a defensive branching strategy and careful file reconciliation, you can retrofit starter kits like Laravel Breeze, Jetstream, or Filament into an established project without breaking production schemas.

The Risks of Retrofitting Starter Kits into Existing Codebases

When you run an installer command like php artisan breeze:install or php artisan jetstream:install, the package executes scaffolding stubs that assume a default directory layout. In an existing application, this creates several immediate points of failure:

• Route Overwrites: The installer routinely appends or replaces route definitions in routes/web.php and routes/auth.php, potentially eclipsing custom middleware groups or URL patterns.
• Model Collision: Scaffolding stubs overwrite or heavily modify app/Models/User.php. If your existing User model includes custom casts, scopes, relationship methods, or soft deletes, a blind overwrite wipes them out.
• Migration Redundancy: Starter kits push new migration files for password resets, sessions, two-factor authentication, or personal access tokens. If your database already has these tables with custom index names or foreign keys, running php artisan migrate triggers fatal SQL collision errors.
• Frontend Build Pipeline Drift: Starters overwrite vite.config.js, tailwind.config.js, and package.json. If your project uses custom PostCSS plugins, custom aliases, or Tailwind plugins, your frontend build will break immediately.

Always create an isolated Git branch (such as feature/retrofit-starter-kit) before running any installation command.

Breeze vs. Jetstream vs. Filament: Choosing the Retrofit Target

Before adding a kit, assess the architectural weight and frontend footprint of each option against your application's current stack:

If your existing application is built on standard Blade templates and you only need clean authentication, Laravel Breeze with Blade is the lowest-risk target. If you need dedicated administration consoles without touching your customer-facing routes, Filament can be mounted on an isolated path (like /admin) with dedicated auth guards, avoiding core route collisions altogether.

Step-by-Step: Installing Laravel Breeze on an Existing Codebase

To demonstrate a safe retrofit, consider installing Laravel Breeze into an application running Laravel 11 or 12.

Step 1: Install the Composer Dependency

Require the development dependency without running automated discovery scripts yet:

composer require laravel/breeze --dev

Step 2: Run the Install Command Without Migrating

Run the artisan install command specifying your desired stack, but avoid running the database migration flag:

php artisan breeze:install blade --dark

For Inertia stacks, pass vue or react. The artisan command generates new controllers in app/Http/Controllers/Auth/, views in resources/views/auth/, and configuration files.

Step 3: Perform an Immediate Git Diff Audit

Before touching the browser, run:

git diff routes/web.php app/Models/User.php package.json

Examine every file modified by Breeze. You must manually merge custom logic back into User.php. For example, ensure your existing $fillable array contains your original application attributes alongside the newly introduced name, email, and password.

Resolving Schema and User Model Conflicts

The most delicate part of retrofitting is schema harmonization. Starter kits ship migration files with fixed timestamps. If your database already has a users table, running migrations will fail.

Inspect database/migrations/ for newly created files. If Breeze created a migration to add columns that already exist in your production database:

1. Delete redundant migrations: If your schema already stores email_verified_at and remember_token, delete the newly published duplicate migrations.
2. Write dedicated delta migrations: If the starter requires columns you lack (such as two_factor_secret or profile_photo_path), create an explicit delta migration:

php artisan make:migration add_starter_fields_to_users_table --table=users

Define only the missing fields in your up() method:

public function up(): void
{
    Schema::table('users', function (Blueprint $table) {
        if (!Schema::hasColumn('users', 'two_factor_secret')) {
            $table->text('two_factor_secret')->nullable()->after('password');
        }
    });
}

This defensive check (Schema::hasColumn) prevents production migration failures across staging and local development databases.

Asset Pipeline and Frontend Reconciliation

Modern starter kits install updated dependencies into package.json and overwrite Vite settings. To resolve asset conflicts:

1. Audit package.json: Compare package versions. Do not blindly overwrite your existing UI libraries. Merge the newly added dependencies (such as @tailwindcss/forms or Alpine.js) into your current devDependencies.
2. Reconcile Tailwind Configuration: If your existing project uses Tailwind CSS v3 and the starter kit pulls Tailwind CSS v4, keep your established theme extensions and color palettes intact.
3. Isolate Layouts: Starter kits drop an app.blade.php and guest.blade.php into resources/views/layouts/. If your application already has an app.blade.php, rename the starter layout to resources/views/layouts/auth.blade.php and update the view references in resources/views/auth/*.blade.php accordingly.

Run your build command to verify that your existing front-end scripts compile cleanly:

npm install
npm run build

Testing and Verification Checklist

Before opening a pull request to merge your starter kit into your primary branch, verify these operational paths:

• Authentication Flow: Test user registration, login, logout, and password resets against your active mail driver (using Mailpit or Log in local dev).
• Existing User Access: Confirm that existing user accounts can authenticate successfully without password hash incompatibilities.
• Route Authorization: Verify that your existing application routes protected by auth middleware continue to function properly.
• Frontend Regression: Check that your existing pages render without missing Tailwind classes, broken navigation bars, or asset 404 errors.

Accelerate Your Laravel Stack with Ship Templates

Retrofitting starter kits into legacy systems is manageable, but when launching new ventures, starting with an unopinionated, production-ready foundation saves dozens of engineering hours.

Explore our directory of pre-configured, production-tested solutions:

• Explore All Laravel Templates
• Browse Full-Stack SaaS Starter Kits
• Find Turnkey Starter Kits
• Discover Laravel Admin Panel Templates
• Browse All Framework Templates