Laravel is an open source framework written in PHP, and it settles where the code of a system lives rather than what that code decides. The screens, and the conditions a record has to meet before it is accepted, are written on top of it. So a framework name in your paperwork guarantees less than it appears to.
What Laravel is: not a language, not a ready-made site, but an open source framework written in PHP
Several different things get packed into one word. PHP is the programming language a system is written in. Laravel is a framework written in that language, and what it decides is where each piece of code belongs. Its own installation page puts the job plainly: a framework supplies a structure and a point to start from when an application is built. The same page notes that PHP has to be present on the machine before any Laravel application can be created.
Structure is worth unpacking, because it is the part of the definition a buyer can actually use. Route definitions live in a known place. The classes that map onto database tables live in another. The rules that incoming input is checked against live somewhere else again. None of those addresses change from one project to the next, which is why a developer opening the codebase for the first time knows where to look without anyone pointing.
Producing the screens, and the rules behind them, from nothing is a separate piece of work, whose scope the web development page describes; this article only draws the line around it. A theme ships finished screens and finished rules, which is where it parts company with a framework: a framework ships neither, and offers only the place where each of them gets written.
A licence writes no business rules, and that is the only part of the licence question this article needs. Laravel is distributed under a permissive open source licence, the MIT text; what a licence of that kind grants and never takes on is the subject of the article on open source.
A site built with a tool like WordPress arrives with working screens attached, which is the theme-versus-framework question approached from the other end. One route begins with screens that already exist and the other begins with an empty structure, and neither is being ranked here. Where the decision really turns is set out in the guide comparing WordPress with a custom corporate site.
An inventory entry and a preference are not the same thing, and a framework name can be either. The KGM SsangYong corporate site reached us already serving its pages, with the name sitting in its documentation as a fact to work around rather than a decision to make. Read that same name in a proposal still under discussion and it is somebody’s choice, open to argument.
What Laravel is used for: brochure pages and incoming requests sit in one codebase
The worry underneath this question is usually a financial one. If the public pages are one system and the requests arriving from those pages are another, each of them gets bought, hosted and maintained separately. Diotek’s HVAC site answers it inside a single codebase: Inertia handles page transitions in the browser while routing and validation stay in Laravel; requests and content share one MySQL schema.
Sharing a schema has a mechanical consequence worth naming. Nothing has to be copied from one store into another, so there is no transfer step to write, watch and repair. Where separate systems exist, that step is the part that fails quietly, and the argument about which side failed tends to outlast the fault itself.
The same arrangement carries a cost, and it should be said out loud rather than left for later. When content and requests live in one schema, a change on the content side reaches the request side, and each side gets considered in the same maintenance pass. The choice is not free. It trades a transfer layer for coupled changes, and which trade suits you depends on how often each side moves.
On the KGM SsangYong corporate site the model pages, the catalog read path and the store of vehicle image files were all handled as parts of the same installation, which is to say that a framework carries more than pages. So the question has an answer that has nothing to do with new builds at all: often enough, Laravel is simply the thing a currently running system stands on.
A framework arrives with the work that repeats in every system
Laravel’s documentation names what it hands over, and a buyer meets most of those names in a proposal. Routing binds an incoming address to a behaviour, and the routes themselves sit in the project’s route files. Validation ships a set of ready rules for checking what arrives, down to asking whether a value already exists in a database table. Eloquent reads and writes records through a model that corresponds to each table. Migrations put the schema definition under version control so a team can share it. Queues move work that would take too long during a request into a background job. Authentication supplies the tools for signing a user in.
Picture the alternative first. Written fresh in each project, every one of those jobs would carry fresh mistakes, and only the team that wrote them would know where the mistakes sat. Binding addresses to code and checking what a form sends are not interesting problems; they are problems every system has already solved somewhere. That is the saving: not how much code gets written, but how many times the same code gets written.
Which half of a system carries which job is the subject of the article on front end and back end; the axis here is a different one. At Diotek, page changes are handled in the browser while whether a form is accepted is decided on the server, and what matters for this article is not which half owns the job but whether the tool doing it arrived with the framework or had to come out of the trade.
A ready tool is no evidence that the tool has been set up for the way your work runs. The framework was in place on the KGM SsangYong corporate site, and every catalog page view was still paying for the same query against MySQL; arriving ready does not mean arriving configured.
What a framework really delivers, then, is a list of questions with the answers left blank. The rule set is there and the queue mechanism is there, but which rule attaches to which form, and which work belongs in a queue at all, are not. Ready describes the job, never the tuning of it, and the word covers less than a reader expects it to.
Your own rules never arrive written: the framework hands over the tool, the trade writes the rule
Start with the evidence rather than the tool. At Diotek a survey request is about a room; a service request is about an installed unit, and capacity depends on the room, so nobody can quote a unit before seeing the space. A validation rule is able to test whether a field is empty and unable to test whether that field ought to be required here and absent there, because the reason for the difference sits outside the code. How each is kept as its own record is covered in the article on separating bookings from service calls.
Nobody has written the trade down inside a library, which is the limit worth understanding. A tool can be told that a field is mandatory; it cannot work out that the same field matters on a survey and means nothing on a service call. When that never gets explained to whoever writes the code, nothing visibly breaks. The form is accepted, a record lands, no error appears anywhere, and the record itself is the wrong thing.
A copy that gets missed surfaces much later, as a record nobody should have accepted, and that is the real reason to ask where a rule physically lives. Spread across several places, adding or removing a mandatory field becomes a hunt for every copy of the rule. Defined in one place, the same change never reaches the screen code.
How often the underlying data moves is what settles a caching decision, and nothing in the framework settles it for you. On the KGM SsangYong corporate site the record reads: Catalog queries are served from Redis; MySQL only runs when the underlying data changes, not once per visitor per page load. When a cached answer has stopped being true is part of that same decision, and it is nowhere in the framework either. Reads, in other words, carry decisions of exactly the same kind as forms do.
What would not be touched was settled before anything else on the KGM SsangYong site, and only then did the work go into the places carrying the page weight. An inherited system already has its rules written somewhere; reading is the only way to find out where.
Which items come from the framework, and which ones are your call
Some items arrive with the framework, some never do, and that gap is a decision space rather than a shortcoming: the last rows carry the most weight for exactly that reason. Read along a row, and the question of who decides what falls into the cells to the right of whichever item you placed there.
| Work item | Arrives with the framework | Written for your business | What changing it later involves |
|---|---|---|---|
| Which address maps to which behaviour | Routing, which binds an incoming address to a behaviour; the routes sit in the project’s route files | Which paths exist at all: at Diotek each request type opens through a path of its own | A new request type needs a new path and a new kind of record |
| Checking what a form sends | The validation component and its ready rule set, including the check for whether a value already exists in a table | Which field is mandatory on which request: a room and a date for a survey, an installed unit for a service call | Defined in one place, the field set changes without the screen code being opened |
| Where a record sits in the database | Reading and writing through a model that corresponds to each table, with migrations that version a schema change | Which information belongs in which record: at Diotek requests and content share one MySQL schema | Touching the schema concerns every screen that reads that record |
| Which read is answered from a cache | The cache is an item named separately in the stack | Which reads come from the cache, and when a cached answer expires: catalog reads on the KGM SsangYong site | A new kind of content reopens the question of when the cache goes stale |
| What a file name tells you | Naming and folder conventions for vehicle image files do not arrive with the framework | The rule deciding where a vehicle image file belongs was written afterwards on the KGM SsangYong site | Ignore the convention once and adding a model turns into a file hunt |
The money sits in the right-hand column, which is the one most often skipped: what a later change costs depends on where the item started. Read the middle column as a starting point rather than a promise, because the same item closes with a framework tool in one engagement and needs a separately named component in the next. No single direction is being imposed here.
One change is cheap and another is expensive inside the very same system, and a framework name is not what decides which is which. A schema change pulls in every screen reading that record. A change to the mandatory field set stays inside a single definition. The rows, read together, say that much.
The framework can stay while the order of the work is rebuilt
The reasonable worry at this point is about freedom. If the framework is fixed, what is left to decide? On the KGM SsangYong corporate site the framework and the front-end set had to stay, because the site is maintained by the brand’s own team. The order of the work was rebuilt anyway: vehicle image files were moved into one naming convention and catalog reads were put behind a cache, none of which required touching the framework.
The inference is the load-bearing part of this section. If those arrangements could be rebuilt without the framework being touched, then they were never the framework’s call to begin with. A fixed framework locks the tool list. It does not lock the order of the work.
On that site the cache was the only component that joined the stack, and everything else was left as it stood. The jQuery requests on the model pages were therefore not swapped for something newer but worked through one at a time, the front-end set being frozen as well. That is the price of working this way, and the project record names it rather than hiding it: instead of a clean rewrite, the job became a set of smaller moves inside a shape somebody else had drawn.
Something that looks like a file-layout problem may turn out to be imposed from underneath, which is why the line cannot be drawn on an inherited system without reading the code first. Knowing in advance which part is independent of the framework is not easy. On that job the line became clear only after the reading pass, and the limit of the intervention was drawn there.
Your business rules do not change because a version changes; what a release transition touches is the part of your code that faces the framework. The framework’s own calendar belongs in the same picture, and Laravel publishes a release and support policy: bug fixes and security fixes for a given major release stop after a stated period, and the periods themselves are written on the policy page. Who carries that watching job is the subject of the article on maintenance after launch.
The name Laravel tells you how the code is arranged, not whether the rules are right
The name says where code gets written and says nothing about whether what was written fits the way a business runs. The framework was in place, and the name was the same one it is today, on the day the KGM SsangYong installation was serving its pages with vehicle images in an inconsistent layout and no clear rule about where a file belonged. Nothing about the name changed when that rule was finally written.
Route files, record classes and validation rules sit in the same relative places in every project, so an incoming team reads a map it already knows instead of one invented for this system alone. That is what the name guarantees, and it is not nothing: whoever opens the code next knows the arrangement in advance. The tool list on the KGM SsangYong site was kept for the same reason, since those are the tools the team carrying the maintenance already knows.
Familiarity is still not fitness. Skip the testing and what you hold is a name and a running system, neither of which tells you anything about fit; whether a rule suits your business is tested, not read off a name. Which scenarios do that testing is set out in the article on what to check before accepting software.
Which screens and which rules were written for your business, where do they live, and what else moves when one of them moves. That is the short list worth asking for. Whoever built or maintains the system has the answers; a framework name has none of them and only tells you where to look.
If a system runs for you and nobody can say which part was written for your business, reading the code and listing what stays and what changes is what the takeover page covers.
