DEV Community

Cover image for Laravel Developers — You’re Probably Using Only 40% of the Framework
Jayesh Paunikar
Jayesh Paunikar

Posted on • Originally published at codewithjayesh.com

Laravel Developers — You’re Probably Using Only 40% of the Framework

And the other 60% is where the real magic lives.

2015, I was deep in a messy PHP project.

Same database query in five different files. Bugs that kept coming back no matter how many times I fixed them. Every small change felt like I was touching something I shouldn’t. I was tired.

A friend sent me a link with zero explanation. Just — “try this.”

It was Laravel.

I spent the whole weekend reading the docs. Clean routes. Eloquent that actually made sense. Migrations. I was completely hooked.

For the next year I used the same things over and over — routes, controllers, models, Blade templates. I thought that was Laravel. I thought I had it figured out.

I didn’t.

Here’s the thing nobody tells you

You can build working apps using just 40% of what Laravel offers. And because those things work fine, most developers never go looking for the rest.

I get it. You have deadlines. The controller works. The query runs. Ship it and move on.

But six months later you open that same file and wonder who wrote it. The controller is 300 lines. The same logic is copy-pasted in four places. A simple bug fix somehow broke two unrelated things.

That’s not bad luck. That’s what happens when you only use the basics.

Laravel already has the solutions baked in. You just have to know they exist. Let me show you two of them — and give you a peek at six more.

The one that made a client think we upgraded the server

I once inherited a project where the dashboard took almost 2 seconds to load. The client was complaining. I opened the code expecting something complicated.

It was 11 database queries. On every single page load. Just for the sidebar menu and user permissions. Data that hadn’t changed in weeks — fetched fresh every time someone opened the dashboard.

I added three lines using Laravel’s built-in cache:

$menuItems = Cache::remember("nav.user.{$user->id}", now()->addHours(6), function () use ($user) {
    return NavigationService::buildFor($user);
});

Enter fullscreen mode Exit fullscreen mode

Page went from 1.8 seconds to under 200 milliseconds.

The client actually called me to ask if we upgraded the server. We did not upgrade the server.

Cache::remember stores the result the first time, then returns the stored version until it expires. That's it. Navigation menus, permissions, settings, statistics — anything that loads slowly but rarely changes is a perfect fit for this.

The one that stopped me writing 300-line controllers

Every Laravel developer has done this at some point.

User signs up → you need to send a welcome email, create their workspace, ping the admin on Slack, assign a default role. So you write it all inside the same controller method because that’s the fastest way to get it done.

Three months later that method is 80 lines and touching six completely different things. Nobody wants to go near it.

Laravel has something called Observers. An Observer watches a model and runs code automatically when something happens to it — when it’s created, updated, deleted. Your controller just does its job. Everything else fires on its own.

class UserObserver
{
    public function created(User $user): void
    {
        Mail::to($user)->send(new WelcomeEmail($user));
        Workspace::createDefault($user);
        Slack::notify("New user: {$user->email}");
    }
}
Enter fullscreen mode Exit fullscreen mode

Controller creates the user. Observer handles the rest. Clean, automatic, easy to find later.

Honestly once I started using Observers I stopped dreading the “can we just do one more thing when someone signs up” conversation. Adding a new action is one method in one file. Five minutes, done.

Six more — with full code and real stories

These two are just the start. On my blog I’ve written up eight of these hidden Laravel features in full — with actual code, and the real situations where I discovered them (usually by doing it the wrong way first).

The other six cover:

  • Collections — chain clean operations instead of writing nested foreach loops
  • Pipelines — handle multi-step logic without nesting conditions inside conditions
  • API Resources — stop a renamed database column from breaking your mobile apps
  • Jobs & Queues — make slow forms respond instantly by moving work to the background
  • Macros — add your own methods to Laravel’s core classes so you stop repeating yourself
  • Lazy Collections — process hundreds of thousands of records without running out of memory All of it is already inside Laravel. No packages. No setup. Just things most developers walk right past.

👉 Read the full breakdown → codewithjayesh.com

You don’t have to learn all eight this weekend. Pick one that matches a problem you’re dealing with right now and start there.

The best Laravel developers I’ve met aren’t the fastest learners. They’re just the ones who never stopped being curious about the tool they use every day.

Follow if you want more of this — real Laravel stuff, no fluff.

Top comments (0)