Laravel 11 arrived on March 12, 2024 with a smaller starting application structure and the launch of Reverb for real-time communication.1
I like the tidier starting point. Fewer framework files to navigate can make a new project less intimidating. The business rules, however, haven’t received instructions to become smaller out of respect for the release.
An ordering application still needs to decide who can change an order, when the change is allowed and how it affects the work already underway. Moving the furniture gives us a nicer room. Somebody still has to decide what happens in it.
What the smaller Laravel structure actually changes
Laravel 11 streamlines the structure for new applications without requiring existing applications to reorganize themselves into it. That distinction is useful if you’re weighing an upgrade against a new build.
The release includes several other capabilities. For a business application, the main question remains which ones help its actual responsibilities.
A simpler starting point is not a finished architecture
The new structure consolidates high-level application configuration and reduces some files that many projects rarely customized. That can improve the developer’s starting experience.
It doesn’t specify how your company’s order adjustments, account rules or fulfillment exceptions should be organized. Those decisions still need a deliberate home.
If an important rule exists in a web request handler, a scheduled task and a staff-only shortcut, simplifying the framework skeleton won’t reconcile the three versions. The code may look easier to navigate while continuing to hold three opinions about the delivery cutoff.
That is an application-design problem, not a complaint about the release.
Real-time updates need an agreed source of truth
Reverb provides a first-party WebSocket server integrated with Laravel’s broadcasting tools. It can help communicate changes to connected users.
For an operations screen, that may mean staff see an order status update without refreshing the page. Useful. It doesn’t determine whether the status was valid or whether the user was authorized to see it.
This is the kind of problem our custom development team enjoys.
The authoritative business change should happen in the application first. Broadcasting communicates it. Treating the visible update as the transaction itself risks confusing an announcement with the thing being announced.
Nobody wants the warehouse acting on a beautifully delivered rumor.
Give one business change a coherent path
Let’s use a fictional ordering system where a customer wants to change a delivery date. It looks like one field in the account page. Behind it are availability, processing cutoffs and work that may already have begun.
The exact design depends on the system. The team should still be able to follow that request from permission check to final outcome.
Keep the related rules close enough to understand
Jimmy Bogard’s vertical-slice approach groups concerns around individual use cases.2 It’s one useful architectural option for changes like this, rather than a requirement imposed by Laravel.
The practical benefit is being able to inspect the relevant permission, validation and state change together. Shared rules still need sensible boundaries; copying them into every feature creates a different maintenance problem.
For the delivery change, clarify which facts are checked against current data and which historical facts must remain unchanged. A customer choosing a new date shouldn’t accidentally trigger a recalculation of an unrelated earlier agreement.
That is the sort of detail worth discussing while the feature is still a drawing.
Follow the work beyond the first save
Recording the new date may trigger updates elsewhere. If another service is unavailable, staff need to know whether the change is complete, waiting or requires attention.
Derek Comartin’s workflow-orchestration work examines how a process spanning service boundaries can continue through asynchronous steps.3 It also highlights why we cannot assume one local transaction rolls back every external effect.
Related read: Laravel 13 brings AI closer. Keep your business rules close, too.
You don’t need an elaborate distributed workflow for every form. You do need an answer when the local save succeeds and an external update fails.
Make retries safe, preserve useful references and expose unresolved work. That gives people a way to recover without guessing which system currently believes which date.
A framework upgrade can support this work, but it shouldn’t become a substitute for it. Review compatibility and the relevant workflows separately, then test the business change under ordinary and awkward conditions.
Zulu Shack recommends using release improvements where they fit while keeping the application’s responsibilities explicit. A smaller skeleton is welcome; forcing an existing application into a new shape purely for visual neatness may offer less value.
Before approving the feature, ask a developer to trace that delivery-date change and a member of staff to explain what they will see if it stalls. If both stories make sense together, you’re in a good place.
The codebase can be tidy and the business can be complicated. They just need a working arrangement.