Hire a senior Laravel developer who also owns the architecture
If you want to hire a Laravel developer for the hard parts – a Laravel upgrade that’s several versions behind, an app that slows down every time traffic grows, or an architecture decision you can’t easily undo – that’s the work I take on. I ship code in your repo and make the calls that go with it.
I’ve spent two decades in production, much of it in PHP: the PHP framework at Yola, the GUMP validation library, 200+ projects at the studio I co-founded, and the architecture work that moved Indiemaker off its original Laravel codebase.
What I’m useful for as a Laravel consultant
- Laravel upgrades across major versions, including apps several releases behind with abandoned packages.
- Performance: Eloquent N+1 queries, slow pages, queue backlogs, memory blowups in long-running workers.
- Architecture: splitting a fat-controller app into modules with clear boundaries, multi-tenancy, payment and billing flows.
- Taking over a codebase from an agency or a departed lead, and making it safe for your team to change.
If you need a mid-level developer to clear a feature backlog, hire one – that’s cheaper and a better fit. I’m most useful where a mistake is expensive.
How I run a Laravel upgrade
Laravel ships a major version roughly once a year, and each release has an official upgrade guide. The process that keeps it boring:
- One major version at a time. Skipping versions turns a series of small, documented changes into one undocumented big one.
- PHP first if needed. Each Laravel release has a minimum PHP version, so a PHP upgrade often has to land first.
- Dependency audit. composer outdated and composer why-not laravel/framework with the target version show which packages block the upgrade. Abandoned packages get replaced or forked before the framework moves.
- Static analysis. Larastan (PHPStan with Laravel awareness) with a baseline, so type errors introduced by the upgrade show up in CI rather than production.
- Mechanical changes with tooling. Rector’s Laravel rules or Laravel Shift handle much of the boilerplate; I review every diff and apply them in small pull requests.
- Ship behind normal deploys. Config and route caches rebuilt, queue workers restarted cleanly with queue:restart, error rates watched through the first day.
The most common Laravel performance problems
- N+1 queries from lazy loading. Model::preventLazyLoading() in non-production environments makes them fail loudly; eager loading with with() and withCount() fixes most of them.
- Missing indexes on foreign keys and the columns used in where and orderBy. Laravel migrations don’t add them for you on every database.
- Work done in the request that belongs in a queue: emails, PDFs, webhooks to third parties. Horizon gives you visibility into Redis-backed queues.
- Unbounded queries – all() or get() on a growing table. chunkById() or lazy() for batch jobs, cursor pagination for APIs.
- No caching discipline: config:cache and route:cache missing from the deploy, or application caches with no invalidation story. See my notes on caching strategy.
- The database itself. Sometimes the fix is in MySQL or Postgres, not PHP. That’s database performance tuning.
Taking over a Laravel codebase
A lot of Laravel work starts with an inherited app: an agency built it, the lead developer left, and nobody is sure what’s safe to change. This is how I’d spend the first two weeks on a codebase like that.
- Get it running locally from the README. If that takes a day, the onboarding docs are the first fix – usually a Sail or Docker Compose setup and a seed script.
- Read the scheduler and the queues. app/Console/Kernel.php (or routes/console.php in newer versions) and the job classes tell you what the system does when nobody is watching.
- Check the deploy. Zero-downtime deploys, migrations that lock large tables, secrets in .env files committed to git – these are the risks that hurt first.
- Write down the five scariest areas with a short note on why, and put tests around the top one before changing it.
Laravel architecture that holds up
Laravel makes it easy to start and easy to end up with 2,000-line controllers. I prefer a modular monolith: domain folders with their own models, actions and tests, and explicit interfaces between them. It keeps one deployable app while making ownership clear. I’ve written about it in modular monolith.
I’m wary of splitting a Laravel app into microservices to fix a code organization problem. It usually trades messy code for messy networking.
Questions
Should I hire a Laravel developer or a Laravel consultant?
Hire a developer when you know what to build and need capacity. Bring in a consultant when the problem is a decision or a risk: a major upgrade, performance under growth, or an architecture that’s fighting you. I do the second kind of work, hands-on, in your codebase.
How hard is a Laravel upgrade across several versions?
The framework changes per version are usually modest and well documented. The difficulty comes from third-party packages that haven’t kept up, the PHP version jump, and missing tests. Go one major version at a time and fix dependencies first.
Is Laravel a good choice for a growing SaaS?
Yes, for most SaaS products. It handles queues, scheduling, auth and billing integrations well, and PHP performance is far better than its reputation. Scaling problems are almost always in the database, queues or architecture, not the framework.
Do you work with our existing developers?
Yes. I work in your repo and review process and pair with the people who’ll own the code afterwards. The aim is a team that can do the next upgrade without me.
Laravel app several versions behind?
Tell me the version, the PHP version and what’s blocking you. In a two-week sprint I’ll map the upgrade path and ship the first steps.
GMT+2 · Full EU overlap · US East mornings