Laravel

Laravel gives each responsibility an obvious home. Most maintainability problems I see come from ignoring those homes: business rules in Blade templates, authorization inside controllers, HTTP calls inside models.

A good controller reads like a summary: authorize, validate through a form request, call the thing that does the work, return a response or resource. When a controller method passes forty lines, it's usually hiding a workflow that deserves a name.

I don't add a service layer by default. For CRUD-heavy features, models, form requests and policies are enough, and wrapping them in services adds indirection without value.

A service or action class earns its place when a workflow spans several models, must run in a transaction, talks to an external system, or is triggered from more than one entry point — a controller, a queued job and a console command. Then giving it one home makes it testable and keeps the rules consistent.

Eloquent is productive until it hides the cost of a query. The classic issue is N+1: a list that lazily loads a relationship for every row. I eager load deliberately, use withCount and aggregates instead of loading collections just to count them, and turn on lazy-loading prevention in development so the problem shows up before production does.

Migrations are part of the design: foreign keys, indexes on the columns used for filtering and tenant scoping, and transactions around multi-step writes. When a query matters, I read the SQL and the query plan instead of trusting the ORM.

API resources keep the response shape separate from the database schema, so renaming a column doesn't break clients. Validation lives in form requests, collections are paginated by default, and errors come back in one consistent format with meaningful status codes.

Authentication depends on the client — session-based for a first-party SPA, tokens for third-party or mobile clients — and authorization still runs on every endpoint.

Policies are where access rules belong: one class per resource, called from controllers, jobs and API endpoints alike. In a multi-tenant application the first check is always “does this resource belong to the current tenant?”, then “does this member's role allow the action?”. Gates cover organization-wide permissions that aren't tied to a single model.

Emails, exports, file processing and calls to external APIs run in jobs. The details that matter in production: timeouts and retry counts chosen per job, backoff for rate-limited providers, a failed handler that leaves a trace, and idempotency — a job that might run twice must not charge twice or send two emails.

Jobs receive identifiers rather than large serialized models, and re-check state when they run, because the world may have changed since they were dispatched.

Events are useful when one action has several independent consequences — an accepted invitation might notify the inviter, write an audit entry and sync a CRM. They're harmful when they hide the main flow: if a step is essential to the operation, it should be a visible call, not a listener someone has to discover.

The filesystem abstraction lets the same code write to local disk in development and S3 in production. Files are private by default and served through short-lived temporary URLs after an authorization check; storage paths include the tenant; and heavy exports are generated in queued jobs that notify the user when they're ready.

Laravel makes the common SaaS building blocks straightforward, but the design choices are still yours: global scopes or explicit scoping for tenant data, middleware that resolves the current organization, policies aware of membership roles, one entitlement check for plan features and usage limits, and webhook-driven subscription state.

Each third-party integration gets its own client class with timeouts, retries and error mapping, configured per environment. Inbound webhooks are verified, logged and handed to a job, so the provider gets a fast response and processing can be retried safely.

Feature tests that exercise HTTP endpoints and jobs give the most confidence per line: they cover validation, authorization, the database and the response together. Unit tests are for logic with real branching — pricing rules, entitlement calculations, date handling.

I avoid tests that only restate the framework, such as asserting that a relationship method returns a relationship. Valuable tests assert business outcomes — and especially the actions that must be denied.

A Laravel application in production is more than the web server: supervised queue workers, the scheduler running, config and routes cached at deploy time, logs going somewhere searchable, and deployments that run migrations safely and restart workers so they pick up new code.