You can also use a custom starter kit from a community maintained package, like the one I put together for this talk. This starter repo includes all the tips from this presentation pre-packaged to use for a fresh app, or to browse and copy-paste into an existing app as you wish.

I want you to focus on the tips and not worry too much about taking notes. You might not absorb all of them immediately, but that's okay.

You might go back to work on Monday and immediately apply one or two. You might be 6 months in the future and find yourself looking up a tip you vaguely remembered from today without even realizing it. This talk is about getting general knowledge to you, not going deep on every topic.

Have you ever gone back to a starter kit after making your app?

They get updated with new features and best practices all the time, so you should go back and check the recent commits once in a while to see what new apps get out-of-the-box.

If you check this, you'll see the cool stuff every new Laravel app is getting

For example, the Livewire starter kit now comes with Blaze, which optimises Blade's component rendering a ton

With Blaze, you can get up to 97% faster component rendering, a huge boost if you're using something like Flux UI

Blaze is opt-in

CarbonImmutable fixes this by returning a new instance on every operation, so your original date is never modified. One line in the service provider and now every date across your entire app - now() , model date casts, everything - comes back as a CarbonImmutable.

Carbon dates are mutable by default, which can lead to some sneaky bugs. If you do $end = $start->addDay() , you might be surprised to find that $start has also changed - they're both pointing to the same object.

CarbonImmutable fixes this by returning a new instance on every operation, so your original date is never modified. One line in the service provider and now every date across your entire app - now() , model date casts, everything - comes back as a CarbonImmutable.

This allows positive commands like migrations and seeds, but prevents us running any commands that might delete any of our data.

We're probably using these commands in local development a lot though, so we only want to prohibit destructive commands when the app is in production.

You can set the default requirements on Laravel's password rule. Now everywhere you use the 'password' validation rule, it'll consistently abide by these checks

An important one here is the `uncompromised` rule, which checks the password against haveibeenpwned and prevents users signing up with known insecure passwords

• Disables mass assignment protection globally, so you never need $fillable or $guarded on your models.
• Reduces boilerplate — just add columns to your migration and use them immediately without touching the model.

• Enables three strict-mode checks at once: prevents lazy loading, accessing missing attributes, and silently discarding non-fillable attributes.
• Passing !app()->isProduction() means you catch bugs loudly in dev/staging without risking exceptions in production.

• When a relationship is accessed on one model in a collection, Laravel automatically loads it for the entire collection — no explicit with() needed.
• A great complement to preventLazyLoading() — you get automatic N+1 prevention without having to remember to eager load everything up front.

By default, Laravel stores the full class name (like App\Models\Post) in the morph_type column. This couples your database to your namespace structure - if you ever rename or move a model, the stored values in your database become stale.

With a morph map, you map each model to a short string like the table name instead. The database stays clean and decoupled from your code structure.

Laravel Pint is an opinionated PHP code style fixer built on top of PHP-CS-Fixer. It ships with the Laravel preset out of the box, so there's very little config needed.

Rector is a PHP refactoring tool that can automatically upgrade your code to use modern PHP features and best practices.

There's also a Laravel-specific extension for Rector that adds a bunch of Laravel-specific rules .

The starter kits include a GitHub Actions workflow for linting your code.

But it also includes an optional, commented-out step, which I love uncommenting

This step lets the linters automatically commit changes back to your branch. No need to see a failed pipeline because of a missing trailing comma, no need to have slow precommit hooks on your machine, just let CI deal with it and you'll never think about code style again.

Dependabot is a free GitHub service that automatically opens pull requests to keep your dependencies up to date. All you need is a small YAML file in your repository.

Configure each ecosystem you use - composer for PHP packages, npm for JavaScript, and github-actions to keep your workflow versions current too.

Without it, it's easy to fall months or years behind and miss critical security patches.

By default, Dependabot opens one pull request per package. On a Laravel app with dozens of Composer dependencies, that's a lot of PRs to review.

Use groups to batch minor and patch updates together into a single pull request, keeping things manageable while still surfacing security updates clearly.

PHPStan is a static analysis tool that will analyse your code to understand how it works and find issues without needing to execute it.

But there's a wrapper around this called Larastan which comes with a lot of Laravel-specific rules in addition, and it better understands how Laravel works so will find more issues specific to Laravel applications, and not report as many false positives due to Laravel's use of magic methods.

One thing missed by this is support for Laravel Blade, since they're not typical PHP files. Luckily there's another extension called Bladestan that adds support for that.

Pest is one of the options for running tests in PHP. It uses PHPUnit under the hood.

It does offer lots of other things as first-party features; running in parallel, browser testing, stress testing, type coverage, mutation testing, snapshot testing, etc.

Pest has a built-in concept of architecture tests - tests that don't test your business logic, but instead enforce rules about how your codebase is structured. These presets cover common rules for PHP, security, and Laravel specifically, like ensuring you're not using `eval()`, `dd()`, or `sleep()` anywhere in your app code.

Laravel Debugbar is a package that integrates PHP Debug Bar into your Laravel app. It shows you queries, requests, exceptions, views, route info, and much more - all in a collapsible toolbar at the bottom of the page. It's invaluable during local development.

Laravel IDE Helper generates helper files that give your IDE full autocompletion and type awareness for Laravel's facades, models, and magic methods - things that would otherwise appear as unknown to static analysis tools.

Add these to the post-update-cmd scripts and IDE helper files will be regenerated every time you run composer update, so they always stay in sync with your installed packages and models without any manual effort.

Not every starter kit is made equal, though. Even if you're using Livewire, you might be writing a lot of custom CSS and JS, but the starter kit doesn't include tools like ESLint and Prettier out of the box, which the React/Vue starter kits do.

So it's a good idea to install these tools, copy over the config files and make sure you have them set up too.

But if you're using Livewire, you're also writing your templates in Blade, so make sure to install the Prettier plugin for Blade and set it up too, to format your views.

Since Laravel already uses Vite for asset bundling, you may as well use Vite's test runner Vitest for your JS too. There's very little extra config to add, but t gives you the same kind of Jest/Pest test style you might expect from the rest of the ecosystem.

You can configure Laravel to aggressively prefetch Vite assets - it's a small progressive enhancement that tells the browser to request the extra JS/CSS asset files upfront.

In tests, Vite will throw exceptions if the manifest isn't built. Call withoutVite() in your beforeEach to disable it across the board - no more "Unable to locate file in Vite manifest" errors in CI, nor do you need to wait for npm builds before your PHP tests can run

There are a lot of package managers in the JavaScript ecosystem. npm is the original and comes bundled with Node.js. Yarn came along as a faster, more reliable alternative. pnpm brought disk-space efficiency with its content-addressable store. And then there's Bun.

Use Bun. It's a drop-in replacement for npm - just swap npm for bun. It's dramatically faster at installing packages and running scripts, has a built-in test runner, bundler, and TypeScript support out of the box. There's very little reason not to switch.

For a Laravel app, swap out npm for bun everywhere in your composer scripts, CI pipelines and your README. Your team will thank you for the faster installs alone.

Both nvm and fnm read the .nvmrc file automatically. nvm is the battle-tested original, but fnm is worth considering because it's written in Rust and has near-instant shell startup time.

Either way, adding a .nvmrc is the important part - it means a new developer can clone the repo and just run `nvm use` or `fnm use` and be on the exact right version immediately.

Add this one line to the post-update-cmd section of your composer.json.

Every time you run composer update - whether you're pulling in a new package or upgrading an existing one - Boost will automatically regenerate all of its guidelines to stay in sync with your exact dependency versions. You never have to think about it.

If your app has authentication, you're logging in constantly during local development - probably dozens of times a day.

If you seed a default user in your dev environment, just prefill the login form values when running locally. It's a tiny change, but it means you can just hit submit instead of typing credentials every single time.

The values are only prefilled when app()->isLocal() is true, so they'll never appear in production.

Laravel's default starter kits come with translations like this - passing full strings through to the translation function

That's simple to implement, but not good practice for maintainability. You should instead do one of two things...

Either use properly namespaced keys for your translations if you're going to localise your app, or just remove the translations to make it easier for you to write code if it'll only be one language.

These are all ways of doing basically the same thing: retrieving a value from the request.

But it's a bit more difficult when you're pulling multiple different values. Now it's not clear if these are strings, booleans, arrays or something else...

Luckily, Laravel provides helper methods that return a properly typed value, which makes your IDE and tools like PHPStan happy, and makes sure you're not getting bad data back that's getting malformed as it gets cast from one type to another

The same works for several things; not just requests, but also cache, query strings, Blade component attributes, validated rules, etc.

Spatie's laravel-error-solutions package enhances Laravel's error pages with extra actionable information to help you diagnose and fix problems faster.

Exceptions can now surface more context about what might have gone wrong - including links to relevant documentation and suggested solutions to guide you in the right direction.

Even better, some exceptions can actually fix themselves. With a single click right on the error page, the fix is applied for you automatically - no manual digging required.

Here's a hidden Laravel feature that not many people know about, it's not there by default but if you add an editor key to your config/app.php , Laravel's exception page will turn file paths from things like the stack trace into clickable links that open directly in your IDE.

It works with PHPStorm, VSCode, Cursor, etc.

Laravel's Context facade lets you attach arbitrary key-value data to the current request lifecycle and even queued jobs triggered in the current request.

Putting something like this in a middleware, you can stash the request URL and a unique trace ID once, and that data will automatically be included in every log entry made during that request - without having to pass it around everywhere manually.

When testing code that makes HTTP requests, Http::fake() lets you intercept them and return pre-defined responses. But what happens to any requests you forgot to fake?

Http::preventStrayRequests() will throw an exception if any HTTP request is made that hasn't been faked. This prevents your tests from accidentally hitting real external services, making them faster, more reliable, and truly isolated.

A lot of project readme files get cluttered with too many sections under different headings, but you can actually omit some

If you have a separate `CONTRIBUTING.md`, `LICENSE.md` or `SECURITY.md` file, GitHub makes those available as different tabs at the top of the readme automatically

So you can focus on what really matters in your project's documentation

If you need contribution guidelines, particularly for open source projects, the contributor covenant can be a good starting point.

And if you're not sure what license to go for because you don't speak legalese, check out ChooseALicense.com, which will help make it super clear in laymans terms what each major license means.

I think project documentation is often overlooked, but a readme is the first thing someone will read about your project, regardless of whether it's open source, or an internal commercial project and someone is getting started with it.

The most important thing is to make sure your installation instructions are clear and easy to follow. Most project docs stop at running `composer install` then `artisan serve`, but there's a lot more steps to run to get all of Laravel's built-in features working properly

So remember to note those things like setting up storage and writeable files

Ideally you'd have all of this in a single easy-to-run script if it starts to get too long

You also need to make sure people can run the app and perform common tasks like running tests or fixing code style. You might also cover this in CI, but it's important to be able to do manually too.

You should also note how deployments are handled for your app. If it's an app people will deploy in multiple places (like an open source project, or a per-client install) there will be steps you need to do for each new install, like defining environment variables or setting up the scheduler.

You also need to remember that there are steps you should take in a certain order when doing deployments, as there's a lot you could miss like clearing caches or restarting queue workers.

This will probably change a lot if you've got zero downtime deployments or continuous delivery or use Forge or Cloud or any number of other deployment methods. Just make sure it's documented.