Laravel Development: How We Build, Test and Scale Laravel Apps

What production-grade Laravel looks like: reliable queues with Horizon, tests you can trust, honest Octane trade-offs, and admin panels and APIs built to last.

Inferne Team 7 min read

One application drawn at three stages: a single block, then a queue with one worker, then several worker lanes.

Teams hire us for Laravel development when they want to ship a product quickly without paying for that speed later. The first version is the easy part, because authentication, queues, mail, scheduling, file storage and an ORM all come with the framework. The second year is harder. Traffic grows, jobs pile up, and the codebase has to absorb features nobody planned for.

On every build, we aim for the same things. Background work should be reliable and easy to observe. Tests should be fast and trusted, upgrades should be routine rather than dreaded, and the admin panel your operations team lives in should be quick and safe to use.

What we build with Laravel

  • SaaS products with subscriptions, teams, roles and billing
  • Marketplaces and booking platforms with payments, payouts and notifications
  • Customer portals and back-office tools for operations, finance and support teams
  • JSON APIs behind mobile apps and single-page front ends
  • Integration hubs that keep ERPs, CRMs, payment providers and your own product in sync

We also take over existing Laravel applications and migrate products to Laravel from older PHP stacks, most often CodeIgniter or code written without a framework.

Our approach to Laravel development

We start with discovery. Our business analysts map the user flows, the data model and every integration, since integrations are where estimates usually go wrong. Then we design the domain before any screens, deciding which records are the source of truth, which operations have to be atomic and which work can run in the background.

Controllers stay thin. Business logic goes into small action or service classes, which can be called from a controller, a job or a console command and tested on their own. Schema changes live in migrations. Files go through Laravel’s storage layer, which makes local disk and cloud storage interchangeable. In development we run Eloquent in strict mode, so lazy loading and silently discarded attributes throw errors rather than hiding N+1 queries and lost data.

Every pull request runs the test suite, plus Larastan for static analysis and Pint for formatting. Before release, our QA testers check each feature against its acceptance criteria. Deploys are automated, and migrations are written to be safe while the previous version is still live.

Queues and Horizon, done properly

When a Laravel application fails quietly, the queue is the most likely place. Emails, exports, webhooks and third-party syncs all end up there, so we take job design as seriously as API design:

Three queue lanes sorted by urgency feeding workers, failed jobs dropping into a tray, and a gauge watching the waits.
  • Jobs are idempotent. Any job may run more than once, so running it twice has to be safe. We pass IDs rather than large payloads and check state before acting.
  • Jobs are dispatched after commit. A job dispatched inside a database transaction can start before the commit and find nothing.
  • A job’s timeout is always shorter than the connection’s retry_after value. Otherwise a slow job can be picked up by a second worker while the first is still running.
  • Job middleware handles rate limits for third-party APIs, protection against overlapping runs, and throttling for jobs that keep failing.
  • Queues are split by urgency, so a large import never delays a password reset email.

For Redis-backed queues we run Horizon. You get a dashboard of throughput, wait times and failed jobs, and the supervisor and worker configuration lives in code, under version control. Deploys restart the workers so they never run stale code, and alerts go off when wait times grow. The scheduler runs from a single cron entry, with overlap protection and single-server execution for any task that mustn’t run twice.

Testing, performance and the Octane question

Tests you can trust

Most of our tests are feature tests. They call real routes against a real database, use model factories for data, and rely on Laravel’s fakes for the outside world: queues, mail, notifications, storage and HTTP calls to third parties. Unit tests cover the logic that deserves them. Dusk browser tests cover the few flows where JavaScript behavior matters. The suite can be Pest or PHPUnit, and either way it runs in parallel in CI and stays fast enough that nobody is tempted to skip it.

Parts assembled and torn down for every request beside a flywheel kept spinning that slowly leaks an amber drop.

Performance

Most Laravel performance problems turn out to be query problems: N+1 relationships, missing indexes, and filtering or paginating in PHP when it should happen in SQL. After those come synchronous calls to slow APIs, and production servers running without cached config and routes. We use Pulse or an APM to see where the time actually goes, and fix that first.

Octane

Octane keeps your application booted in memory between requests, running on FrankenPHP, Swoole or RoadRunner. If framework bootstrap is a large share of each request, you’ll see a real gain. The trade-offs are real too:

  • State can leak between requests. Singletons that capture the request, config or current user, and static properties used as caches, cause bugs that only show up under load.
  • Memory grows over time, so workers need a maximum request count and monitoring.
  • Some packages were never written for long-lived processes.
  • If most of the request time is spent in the database, Octane changes little.

We recommend Octane once profiling shows that bootstrap time matters and the codebase has been audited for request-scoped state. We don’t reach for it as a first fix.

Admin panels and APIs

Almost every product needs a back office. For most of them, Filament gets a capable admin running quickly, with resources, filters, bulk actions, dashboards and forms built on Livewire. Nova, Laravel’s paid first-party panel, is a solid alternative if your team prefers it.

Sometimes the back office is really a second product, with complex workflows and a lot of custom UI. In that case we build it with Inertia and a JavaScript front end rather than fight a panel’s conventions. Either way, authorization lives in policies, not in which buttons happen to be hidden.

Our APIs use form requests for validation, API resources for stable response shapes, versioned routes, cursor pagination for large collections and per-client rate limits. Sanctum covers first-party single-page apps and mobile apps. Passport is for the cases where you really do need to act as an OAuth2 server for third parties. Each API ships with an OpenAPI description, so front-end and mobile developers don’t have to guess.

Lumen, Laravel’s former micro-framework, is no longer recommended for new projects, so small services get the full framework as well. Our backend development article has more on API design.

When Laravel is the right choice, and when it is not

For new PHP products, Laravel is our default. It suits SaaS, portals, marketplaces and APIs where delivery speed, a big community with plenty of packages and a deep hiring pool matter. Its first-party packages cover authentication, queues, real-time broadcasting, monitoring and deployment, which leaves you with fewer decisions to make and fewer unmaintained dependencies to carry.

It isn’t the answer to everything. Workloads built around many long-lived connections are often a more natural fit for Node.js or Go. For a content-led website, a CMS saves you from building one. And if your team writes C#, a .NET stack will serve you better than a Laravel app nobody in-house can maintain. The language-level practices underneath all of this are covered in our guide to PHP development.

How an engagement works

A typical Laravel team puts a business analyst and a product designer together with backend and front-end engineers and a QA tester, sized to the scope. On an existing application, we can start with a focused audit of the code, queues, performance and upgrade path, then carry on as your team or alongside it.

Before work begins, we sign a non-disclosure agreement and an intellectual property agreement, and the repository is yours from the first commit. Each iteration ends with a working demo, and you get regular written reports on progress, risks and decisions. We plan framework upgrades into the roadmap, because once an application has skipped several major versions, a routine task turns into a project.

Frequently asked questions

Can you take over an existing Laravel application?

Yes. We audit the code, tests, queues and infrastructure, fix whatever threatens stability, and then pick up the roadmap. Thin documentation is normal, and we write it as we go.

Should we use Octane?

Only if profiling shows that framework bootstrap is a meaningful part of your response time, and the code has been checked for request-scoped state. Database and caching fixes usually come first.

Filament or a custom admin panel?

Filament for most back offices, since it’s quick to build and easy to maintain. Go custom when the admin is effectively a second product with complex workflows of its own.

How do you handle Laravel upgrades?

One major version at a time. The test suite is the safety net, and automated tools make the mechanical changes. Staying current costs far less than catching up.

Can Laravel power the backend of our mobile app?

Yes. With Sanctum tokens, versioned JSON APIs, queued push notifications and a solid admin panel, it makes a practical backend for iOS and Android apps.

If you’re planning a Laravel product, or you already run one whose queues and upgrades need a steady hand, send us a short description of the application. We’ll come back with questions, a proposed first step and a straight answer on whether Laravel is the right fit.