PHP Web Development Services with Laravel 13 and Symfony
PHP web development means building server-rendered web applications and APIs in PHP, which in August 2026 means PHP 8.5 on Laravel 13 or Symfony rather than hand-written scripts. Mixcore Studio builds new PHP applications, takes over existing ones, and upgrades codebases that have drifted onto versions no longer receiving fixes. We have shipped production software for more than 8 years, with 320+ projects delivered across web, mobile and enterprise systems.
An earlier version of this page argued that PHP's advantage was being supported by almost every hosting provider. That was a reasonable sales point in 2021 and it is no longer the reason to choose PHP. Modern PHP runs in containers on managed platforms, is type-declared throughout, and is checked by static analysis in CI before anything merges. The stronger argument today is architectural. After a decade of client-heavy single-page applications, the industry moved back to server-driven rendering, and PHP never left it.
What we build with PHP
- Business applications — internal tools, admin platforms, booking and inventory systems, and multi-tenant SaaS products built on Laravel 13 or Symfony.
- APIs and back ends — JSON and REST services behind mobile apps, JavaScript front ends and third-party integrations, with contract tests and versioned endpoints.
- Commerce and content platforms — catalogue, checkout, payment and publishing systems where server-rendered HTML gives the fastest first paint.
- Legacy takeover and upgrades — inheriting a codebase with no original team, documenting it, getting it onto a supported PHP and framework line, and putting tests around it.
- Integration work — connecting PHP applications to ERP, CRM, accounting, logistics and payment providers, including the queue and retry behaviour those integrations need to survive.
What changed in PHP 8.5
PHP 8.5.0 was released on 20 November 2025, and patch releases have followed roughly monthly since. It is a practical release rather than a headline one, and several of its additions remove code that teams used to write by hand.
- The pipe operator
|>— chains a value through a series of callables, replacing deeply nested function calls that were previously read inside out. - clone with — creates a copy with updated properties in one expression, which makes immutable value objects far less tedious to write.
- A native URI extension — parsing that follows RFC 3986 and the WHATWG URL specification, in place of the assorted regular expressions and userland libraries most codebases carry.
- The #[\NoDiscard] attribute — flags functions whose return value must not be ignored, catching a class of silent bug that static analysis previously had to guess at.
- array_first() and array_last(), persistent cURL share handles, and closures and first-class callables in constant expressions.
None of this is a reason on its own to upgrade a working application. The reason to upgrade is support: PHP 8.1 and earlier are behind the supported line, and running them is a security decision, not a technical preference.
Laravel 13, Symfony 8.1 and the support-window question
Laravel 13 was released on 17 March 2026. It requires PHP 8.3 as a minimum and supports 8.3 through 8.5, adds PHP attribute-based configuration and Cache::touch(), and follows Laravel 12 from February 2025. Its published windows are bug fixes through Q3 2027 and security fixes through Q1 2028.
Symfony runs a different calendar. Symfony 8.1, released in May 2026, is the current stable line, requires PHP 8.4 or newer, and reaches end of support in January 2027. Symfony 7.4 from November 2025 is the current LTS: it requires PHP 8.2 or newer, takes bug fixes until November 2028 and security fixes until November 2029. Symfony 6.4 LTS runs to November 2027, and Symfony 8.0 went unmaintained in July 2026. Minors land every May and November, majors every two years.
That difference is the real decision. If your organisation budgets a framework upgrade every year or two and wants the larger ecosystem and faster delivery, Laravel 13 is the better fit. If you need to promise a compliance or procurement team a supported line stretching into 2029 without a major version bump, Symfony 7.4 LTS is the only PHP option that currently offers it, and we will recommend it even though it is the less fashionable answer.
Buyers now ask about patch cadence in the first meeting, and they are right to. React2Shell (CVE-2025-55182), a CVSS 10.0 unauthenticated remote code execution flaw in React Server Components, was disclosed on 3 December 2025 and added to CISA's Known Exploited Vulnerabilities catalogue as actively exploited. Vercel responded by formalising a Next.js Security Release Program on 13 July 2026, with roughly monthly pre-announced releases and named LTS lines. Whatever stack you pick, you should know which release line you sit on, when it stops receiving security fixes, and how quickly your agency can ship an emergency patch. We answer those three questions in writing at the start of an engagement.
Modernising a legacy PHP codebase
Most PHP work that reaches us is not a new build. It is an application that runs the business, was written by people who have left, and sits several versions behind. The instinct to rewrite it is usually wrong, because a rewrite pauses delivery for a year and discards behaviour nobody documented.
- Measure before touching anything — inventory PHP version, framework version, extensions, and the dependencies that block an upgrade, then produce a costed order of work.
- Get onto a supported line first — PHP 8.1 and earlier, Laravel 12 and below, Symfony 8.0 and 7.3 are all behind the current line. Security support is the first thing to restore.
- Automate the mechanical part — Rector handles the bulk of syntax and API migration; PHPStan or Psalm at a rising baseline stops new code regressing while the old code is cleaned.
- Add tests around behaviour, not implementation — characterisation tests on the paths that carry money or data, so the upgrade is verifiable rather than hoped for.
- Replace incrementally — route by route behind the existing front controller, so the application keeps shipping throughout instead of going dark.
Where PHP is the wrong choice
PHP is a good default for server-rendered applications and APIs. It is a poor default for several things, and we would rather say so before a contract than after.
- Isolate-native edge deployment — if your architecture requires running on Cloudflare Workers or a similar V8 isolate platform, PHP does not run there and a TypeScript back end is the correct answer. Note that the broader edge push has narrowed: Next.js has deprecated
export const runtime = 'edge', and Vercel now recommends migrating from its Edge runtime to Node.js. - High-concurrency long-lived connections — real-time collaboration, chat fan-out and streaming telemetry fit a persistent-process runtime better than PHP's request lifecycle. It can be done in PHP, but you will be maintaining the unusual part of the stack yourself.
- Numerical, model-training or data-science workloads — that ecosystem is Python's, and bridging it into PHP adds a moving part for no gain.
- One language across the whole team — GitHub's Octoverse 2025 reported TypeScript becoming the most-used language on GitHub, passing Python at 2.6M contributors and JavaScript at 2.15M. If shared types between front and back end and a single hiring pool matter more to you than anything above, a TypeScript back end is a defensible choice and we build those too.
- Migrating a healthy application to PHP for its own sake — if you have a working .NET or Node system and a team that understands it, the migration cost almost never returns.
Performance, accessibility and code provenance
Server-rendered PHP starts with an advantage on Largest Contentful Paint and usually loses ground on Interaction to Next Paint, because INP is a JavaScript problem regardless of what rendered the page. Google's thresholds are unchanged: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, assessed at the 75th percentile of real-user field data over a rolling 28-day window. If you have bolted a client-side navigation layer onto a PHP application, be aware that Chrome 151 shipped soft-navigation measurement unflagged in July 2026, so route changes that previously went unmeasured can now be reported.
For the front end of PHP applications we use Vite 8, released 12 March 2026, which replaced the old esbuild-for-dev and Rollup-for-build pair with Rolldown as a single Rust bundler. The Vite team reports 10 to 30x faster builds, with case studies including Linear at 46s to 6s and Ramp at a 57% reduction. Slow pipelines are now a cost you can choose not to pay.
Accessibility has hard dates attached. The European Accessibility Act (Directive (EU) 2019/882) has applied to newly marketed products and services since 28 June 2025, covering e-commerce, banking, e-books and passenger transport among others. The US Department of Justice ADA Title II rule sets WCAG 2.1 Level AA deadlines of 26 April 2027 and 26 April 2028. We build to WCAG 2.2 AA, which is the current W3C Recommendation, and hand over the conformance evidence rather than an overlay plugin.
On code provenance, we are direct about it. DORA's 2025 State of AI-assisted Software Development report found 90% of respondents using AI at work, with adoption now positively related to delivery throughput but still negatively related to delivery stability. The Stack Overflow 2025 Developer Survey of over 49,000 developers found 84% using or planning to use AI tools while only 3% highly trust the output, and 66% naming AI solutions that are almost right, but not quite, as a top frustration. Our position follows from those two findings: AI can draft, but a named senior engineer reviews every change, and the test suite and static analysis gate are what actually decide whether it ships.
Our expertise
- Laravel 13 development
- Symfony 7.4 LTS and 8.1
- Legacy PHP upgrades
- API and integration back ends
- Static analysis and testing
- Performance and Core Web Vitals
Frequently asked questions
Is PHP still a sensible choice for a new project in 2026?
Yes, for server-rendered applications and APIs, which is most business software. The architectural argument that ran against PHP for a decade has reversed: server-driven rendering is the mainstream answer again and client-only rendering is now the exception that has to be justified. PHP 8.5 with Laravel 13 or Symfony gives you a typed language, mature tooling and a large hiring pool. It is the wrong choice for isolate-based edge runtimes, high-concurrency real-time connections and data-science workloads.
Should we build on Laravel 13 or Symfony?
Laravel 13, released 17 March 2026, is the faster path for most product teams and requires PHP 8.3 or newer, with bug fixes through Q3 2027 and security fixes through Q1 2028. Symfony suits organisations that need long, predictable support: Symfony 7.4 LTS takes bug fixes to November 2028 and security fixes to November 2029, while the current stable Symfony 8.1 requires PHP 8.4 and ends support in January 2027. Pick by how long you need the line supported, not by which is more popular.
We are running an old PHP version. How risky is the upgrade?
Lower than a rewrite, and the risk is measurable rather than open-ended. PHP 8.1 and earlier are behind the supported line, so the real risk is staying put. We inventory the blocking dependencies first, use Rector for the mechanical migration, hold a rising PHPStan baseline so new code cannot regress, and add characterisation tests on the paths that move money or data before changing them. The application keeps shipping throughout.
How long will the version you build on stay supported?
That depends on the line we agree at the start, and we put the dates in writing. Laravel 13 has bug fixes through Q3 2027 and security fixes through Q1 2028. Symfony 7.4 LTS has bug fixes until November 2028 and security fixes until November 2029, and Symfony 6.4 LTS runs to November 2027. Symfony ships minors every May and November and a major every two years, which makes budgeting the upgrade straightforward.
Do you use AI to write our code, and who is accountable for it?
We use AI assistance and we are explicit about the controls around it. DORA's 2025 report found 90% of respondents using AI at work, with a positive relationship to delivery throughput but a continuing negative relationship with delivery stability, and the Stack Overflow 2025 survey found only 3% of developers highly trust AI output. So a named senior engineer reviews every change, static analysis and the test suite gate every merge, and accountability for what ships sits with us, not with a tool.
Contacts
We are always happy to talk with you.
Feel free to contact us in any suitable way
Request a quote
Let's discuss your project!
Please, provide us with a brief description of what you
already have and what you are going to achieve.
Mail us contact@brainiacminds.com