Laravel development
Laravel is what we reach for when something new belongs in PHP. A product to build from nothing, a platform to replace, or an internal process that has outgrown the spreadsheet and the two people who understand it.
01Capabilities
What we build when nothing exists yet
This is the greenfield page in our PHP family. What to do with a PHP estate you already own is a different conversation and it lives on the PHP page; an existing Yii2 application belongs on the Yii2 page.
- Booking
Booking and scheduling platforms
Availability, capacity, pricing rules and the payment step, the kind of system behind our hospitality and leisure work. The hard part is never the booking form. It is what happens when two people book the last slot in the same second.
- Commerce
Commerce and order platforms
Catalogue, order lifecycle and the integrations into ERP, fulfilment and accounting, including e-commerce builds that sit alongside an existing storefront rather than replacing it. Laravel is a good fit for the order and back-office layer.
- Tenancy
Multi-tenant SaaS back ends and APIs
Tenancy, roles, billing and the API surface a front end or a mobile client builds against. We design the contract and the tenancy model first, because both are the parts you cannot cheaply change once real customers depend on them. This is our platforms and integration work.
- Workflow
Submission and workflow systems
Structured intake, review stages, approvals and document handling, where the workflow is the product and the rules change every year. Laravel's queues and scheduling cover most of what these systems actually need. We build them under an ISO 27001:2022 certified information-security management system.
02Case studies
Laravel platforms already in front of customers
Three Laravel platforms in production, across e-commerce, hospitality and entertainment.
See all case studies
eCommerceEcommerce software development for JewelCandleJewelCandle, a mid-size European manufacturer of scented products, sells across seven EU countries (B2B and B2C) via online shops.10,000-plusProducts manufactured
HospitalityHighly Adjustable Platform for entertainment industriesunicrew developed a platform for Booked It that enhanced the customer experience for nightclub, entertainment center, and festival goers.600+Businesses using the platform
EntertainmentDevelopment of hybrid events softwareOur client, meta-fusion GmbH, has supported hybrid meetings and the digital processing of congresses and conferences for 18 years, and built the Digital-Congress-Resources Suit (DCR Suit).
03Fit
When PHP is the wrong family entirely
Laravel is our default when a new system belongs in PHP, and that qualifier is doing real work. The framework choice inside PHP is easy. The useful question is whether PHP is the right family for what you are building at all, and often it is not. Four of the six rows below argue against the build you came here for.
| Your situation | What we recommend |
|---|---|
| New product, web first, and a team you will keep hiring PHP engineers into | Use LaravelThe ecosystem, the documentation and the hiring pool are the strongest in the PHP world, and that outlasts any feature comparison. |
| You already run a large PHP estate that works, and somebody has proposed a rewrite | Different pageOur PHP page. Modernize what exists first and let the framework question come last, not the other way round. |
| A small internal tool a handful of people will use, with an off-the-shelf product that fits | Buy, not buildA subscription you can cancel beats a codebase you have to keep. We would rather say that than quote the build. |
| The product is really a data pipeline or a machine-learning system | We argue againstPython owns that ground, and pretending otherwise would cost you a rewrite later. |
| Realtime collaboration, streaming, or thousands of connections held open at once | We argue againstNode.js or Go fits that concurrency model. Laravel can still own the rest of the application. |
| A regulated transactional core several teams will maintain for a decade | We argue againstJava or .NET carry the deeper story there, and we would rather lose the build than sell you the wrong foundation. |
Scope
What we own on a Laravel build is the architecture and everything that follows from it. The domain model, the tenancy and permission design, the queue and failure behaviour. And whether your own engineers can still change the codebase after we hand it over. unicrew has been building systems like this since 2012, with 100+ senior in-house engineers across six countries. We hold Laravel partner status and an ISO 27001:2022 certified information-security management system. Where the honest answer is a smaller build than the one you came for, that is the answer you get.
Laravel gets picked because it is fast to start in, and that is a real advantage. The trap is that the conveniences making month one quick (models reached from anywhere, logic living in controllers) are the ones making month eighteen slow. We keep the framework and move the domain rules into classes that do not know Laravel exists. You keep the delivery speed, and the parts that matter stay testable when the framework moves on.
Yaroslav HavrylivSenior Engineering Manager, unicrew04Delivery
The first weeks, and why they decide year three
Four things we settle early, because every one of them is painful and expensive to retrofit once feature work is spread across the codebase.
- Model the domain before reaching for EloquentThe business rules get written down and argued about first. Laravel makes it very easy to let the database schema become your domain model by accident, and that is the single most common reason an eighteen-month-old codebase resists change.
- Fix the tenancy and permission model onceWho can see what, and how tenants are separated, decided up front and enforced in one place. Retrofitting tenancy or a permission scheme into a live product is close to a rewrite of every query in the system.
- Decide the background-work story earlyQueues, scheduled jobs, retries, and what happens to a job that fails at three in the morning. Most production incidents we see on these systems are queue and failure-handling problems rather than request-path problems. Each release goes through the same QA and test automation practice we use on our own builds.
- Deploy to production shape in week oneA real pipeline into an environment that resembles production, with migrations, secrets and observability wired in, before there is much to deploy. It removes the class of surprise that normally arrives at the end. Where the operational side is the larger problem, DevOps consulting covers it.
05Client voices
What the people who own these platforms said
Our platform has been refactored to Laravel ensuring the code base is more stable, easier to maintain and easier to add new features. Their professionalism and quality of work have stood out in the partnership. We have had the code audited by a 3rd party who was extremely complimentary of the work.
The quality of their coding was outstanding to our standards. Overall, their work was key for us. They were dedicated to solving our problems as a customer; their team was collaborative, listened to us, and fully engaged in our space to commit to the project.
06Stack
What a Laravel system sits between
The four things a build like this nearly always has on either side of it. Each has its own page, if the real question turns out to be there.
07Questions
Questions from teams about to start a build
Answered the way we would answer them on the call. If yours is not here, it makes a good first message.
Our engineers can work inside your team, and on a product you intend to own long term that is often the right shape. What we will not do is supply developers into a decision we think is wrong, which is a live risk on new builds because the framework usually gets picked before anyone writes down what the system must do. Team extension is managed teams; handing over the outcome is web development.
Laravel for most product work, because the conventions and the first-party tooling get a team to a working system faster and the hiring pool is larger. Symfony earns the nod where the domain is complex enough that you want explicit configuration over convention, or where your organisation already has Symfony engineers and standards built around them. Neither is a mistake, and anyone who says one is simply better has not asked about your team.
By treating the framework's convenience as a trade rather than a free gift. Business logic lives in domain services, not in controllers or models. Database access goes through explicit boundaries, so a schema change does not ripple through every view. Major-version upgrades are scheduled rather than deferred until the jump becomes a project of its own. Laravel moves quickly, and a codebase three versions behind is a maintenance problem first.
Usually not as the first move, and this is the answer that costs us the biggest project on the table. A full rewrite freezes product work for as long as it runs and leaves you two systems to keep in step. Raise the PHP floor, get tests around the paths that matter, and cut seams first, which is legacy software modernization. Once seams exist, moving pieces across is a choice rather than a bet.
A scoping call with an engineer rather than a salesperson. For a new build we want to know what the system must do, what the hardest constraint is, and what your team can maintain, because those three answers decide the architecture more than any technology preference. What comes back is a written recommendation, including where we would scope smaller than you asked. Most engagements start within two to four weeks.
Three shapes. Time and materials is billed hourly and quoted per project, which suits scope that is still moving. Fixed price is outcome based and quoted per project, and we only offer it after the first read, because a fixed number on a system nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer, for people inside your own planning.
Scoping a new build?
Tell us what the system has to do and what your team already knows. You get a straight recommendation, including the version where the answer is not PHP at all.