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 6 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. Laravel makes the first version easy: authentication, queues, mail, scheduling, file storage and an ORM are there from day one. The hard part is the second year, when traffic grows, jobs pile up, and the codebase has to absorb features nobody planned for.

Good looks like an application where background work is reliable and observable, tests are fast and trusted, upgrades are routine instead of dreaded, and the admin panel your operations team lives in is fast and safe. That is what we aim for on every build.

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 we move products onto Laravel from older PHP stacks, most often from CodeIgniter or framework-less code.

Our approach to Laravel development

Discovery comes first. Our business analysts map user flows, the data model and every integration, because integrations are where estimates usually go wrong. We then design the domain before the screens: which records are the source of truth, which operations must be atomic, and which work can happen in the background.

In the build, controllers stay thin. Business logic lives in small action or service classes that can be called from a controller, a job or a console command and tested on their own. Schema changes live in migrations, and files go through Laravel’s storage layer, so local disk and cloud storage are interchangeable. In development, Eloquent runs in strict mode, so lazy loading and silently discarded attributes throw errors instead of hiding N+1 queries and lost data.

Every pull request runs the test suite, Larastan for static analysis and Pint for formatting. Our QA testers verify each feature against its acceptance criteria before release, and deploys are automated, with migrations written to be safe while the previous version is still running.

Queues and Horizon, done properly

Queues are where Laravel applications most often fail quietly. Emails, exports, webhooks and third-party syncs all end up there, so we treat 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.
  • Idempotent jobs. Any job may run more than once, so running it twice must be safe. We pass IDs rather than large payloads and check state before acting.
  • Dispatch after commit. A job dispatched inside a database transaction can start before the commit and find nothing. We dispatch after commit.
  • Timeouts shorter than retries. A job’s timeout must be shorter than the connection’s retry_after value, or a slow job can be picked up by a second worker while the first is still running.
  • Job middleware. Rate limits for third-party APIs, protection against overlapping runs, and throttling for jobs that keep failing.
  • Queues by urgency. A large import should never delay a password reset email.

On Redis-backed queues we run Horizon. It gives you a dashboard of throughput, wait times and failed jobs, and its supervisor and worker configuration lives in code, under version control. Deploys restart workers so they never run stale code, and alerts fire when wait times grow. The scheduler runs from a single cron entry, with overlap protection and single-server execution for tasks that must not run twice.

Testing, performance and the Octane question

Tests you can trust

Most of our tests are feature tests that call real routes against a real database, with model factories for data and Laravel’s fakes for the outside world: queues, mail, notifications, storage and HTTP calls to third parties. Unit tests cover logic that deserves them, and Dusk browser tests cover the few flows where JavaScript behavior matters. Whether the suite uses Pest or PHPUnit, 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 are query problems: N+1 relationships, missing indexes, and filtering or paginating in PHP instead of in SQL. Next come synchronous calls to slow APIs and production servers running without cached config and routes. Pulse or an APM shows where time actually goes, and we fix that first.

Octane

Octane keeps your application booted in memory between requests, on FrankenPHP, Swoole or RoadRunner. When framework bootstrap is a large share of each request, the gain is real. So are the trade-offs:

  • State can leak between requests. Singletons that capture the request, config or current user, and static properties used as caches, cause bugs that appear only 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 request time is spent in the database, Octane changes little.

We recommend Octane after profiling shows bootstrap time matters and the codebase has been audited for request-scoped state. It is not a first fix.

Admin panels and APIs

Almost every product needs a back office. For most, 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 for teams that prefer it.

When the back office is really a second product, with complex workflows and heavy custom UI, we build it with Inertia and a JavaScript front end instead of fighting a panel’s conventions. In every case, authorization lives in policies, not in hidden buttons.

For APIs we 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 when you genuinely need to act as an OAuth2 server for third parties. Each API ships with an OpenAPI description, so front-end and mobile developers are never guessing.

Lumen, Laravel’s former micro-framework, is no longer recommended for new projects, so small services get the full framework too. More on API design in our backend development article.

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

Laravel is our default for new PHP products. It fits SaaS, portals, marketplaces and APIs where delivery speed, a large ecosystem and a deep hiring pool matter. Its first-party packages cover authentication, queues, real-time broadcasting, monitoring and deployment, which means fewer decisions and fewer unmaintained dependencies.

It is not the answer to everything. For workloads built around many long-lived connections, Node.js or Go is often the more natural fit. 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. For the language-level practices underneath all of this, see our guide to PHP development.

How an engagement works

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

We sign a non-disclosure agreement and an intellectual property agreement before work begins, and you own the repository from the first commit. You see a working demo every iteration and receive regular written reports on progress, risks and decisions. Framework upgrades are planned into the roadmap, because an application that skips several major versions turns a routine task into a project.

Frequently asked questions

Can you take over an existing Laravel application?

Yes. We start with an audit of the code, tests, queues and infrastructure, fix what threatens stability, and then pick up the roadmap. Thin documentation is normal; we write it as we go.

Should we use Octane?

Only when profiling shows 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, because it is fast to build and easy to maintain. A custom panel when the admin is effectively a second product with its own complex workflows.

How do you handle Laravel upgrades?

One major version at a time, with the test suite as the safety net and automated tools making the mechanical changes. Keeping current is far cheaper than catching up.

Can Laravel power the backend of our mobile app?

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

If you are planning a Laravel product or need a steady hand on one that already exists, tell us about your project. We will come back with questions, a proposed first step and an honest view of whether Laravel is the right fit.