Is PHP a Good Choice for Business Projects? When We’d Use It and When We Wouldn’t

PHP is a sound choice when your project sits next to WordPress or another PHP system you already run, when your team works in Laravel, or when you are taking over a PHP app that works. For a brand-new product with no PHP around it, we would usually build the back end in Node.js with TypeScript, so one language covers the front end and the back end. What usually goes wrong is an old PHP version that no longer gets security fixes.

PHP still runs most of the web

According to W3Techs, PHP is used by 69.2% of all websites whose server-side language it can detect (data for 30 October 2026). A large part of that is WordPress, which W3Techs counts on 58.2% of sites with a known content management system, or 39.5% of all websites.

New development work tells a different story. In the 2026 Stack Overflow Developer Survey, 17.7% of all respondents had done extensive work in PHP over the past year, against 62.0% for JavaScript and 58.0% for Python. In the same survey’s framework list, WordPress was at 13.3% and Laravel, the highest-placed PHP framework, at 7.6%.

Put together, there is a lot of PHP running in production and a smaller share of developers starting new projects in it. For a business owner that means two things: PHP developers to maintain an existing app are easy to find, and a new PHP build needs a team that keeps its versions current.

When PHP is the right call

Your situation	Use PHP?	Why
A content site, blog or marketing site on WordPress	Yes	WordPress is PHP, and its editors, plugins and hosting are everywhere
A new app that must work with an existing WordPress or PHP site	Keep the PHP site, connect the new parts	Rewriting a working site adds cost and no value for users
Your in-house team works in Laravel	Yes	The people who will maintain the code already know it
You are taking over a PHP app that works	Usually keep it and upgrade it	An audit decides what to keep, fix or rebuild
A new product with no PHP code and no PHP team	Usually no	We would use Node.js with TypeScript, or Python where the team prefers it

The last row is our preference. Modern PHP with Laravel can run a SaaS. We lean towards TypeScript on the back end for new products because a small team then reads one language from the browser to the database. Our web app development stack lists all three: Node.js with Nest.js or Express, Python and PHP.

FlyDesk: keep the PHP site, build around it

FlyDesk, a coworking booking product, already had its web version on WordPress. It needed mobile apps. We built the MVP for iOS and Android and synced the existing WordPress-based web version with the app’s backend, without rewriting the site. The product listed 577 offers in 26 countries from 44 partners. The FlyDesk case study has the details.

That pattern fits many businesses with a PHP site: leave the part that works, and connect new apps and services to it through an API. The same goes for a WooCommerce shop or an in-house tool written in PHP years ago. Your customers and staff already know it, and an API lets the new app read and write the same data.

Check the version before anything else

The PHP project gives each release branch two years of active support and two more years of security fixes only. After that, nobody patches it. These are the branches supported today:

PHP branch	Active support until	Security fixes until
8.2	31 Dec 2024	31 Dec 2026
8.3	31 Dec 2025	31 Dec 2027
8.4	31 Dec 2026	31 Dec 2028
8.5	31 Dec 2027	31 Dec 2029

If your app runs on anything older than 8.2, it already gets no security fixes. PHP 8.2 stops getting them on 31 December 2026.

Frameworks have their own clocks. Laravel gives each major release 18 months of bug fixes and 2 years of security fixes. Laravel 11 stopped getting security fixes on 12 March 2026, and Laravel 12 gets them until 24 February 2027. Laravel 13, released on 17 March 2026, needs PHP 8.3 or later and gets security fixes until 17 March 2028. WordPress plugins and themes need the same attention: an abandoned plugin is old code running on your site.

What PHP won’t do for you

The original version of this article listed reasons PHP is secure, fast and cheap. Those depend on the people and the process more than on the language.

• Security comes from current versions, reviewed code and safe handling of passwords and keys. No language gives you that by default.
• A free license doesn’t mean a free product. Hosting, updates and the people who maintain the code still cost money every month.
• When you compare quotes for a PHP build, check which ones include version upgrades after launch, and who does them.

Questions to ask a PHP team before you hire them

A good PHP team answers these without a pause. Ask them on the first call:

• Which PHP and framework versions will you use, and when does their security support end?
• Do you manage packages with Composer and commit the lock file, so every server runs the same versions?
• Are there automated tests, and do they run on every change?
• Where do database passwords and API keys live? Our guide to passwords and secrets in your app covers what good looks like.
• Who upgrades PHP, the framework and the plugins after launch, and how often?
• Is the code in a repository that belongs to your company?

Taking over an old PHP app

If your PHP app stalled with another team or a freelancer, find out what you own and what state it is in before you decide anything.

Our code audit costs a fixed $3,500 and takes 5 working days. You get the list of accounts the product depends on and whose name each is in, the state of the code, security problems with the worst first, and a keep, fix or rebuild call for each part, with hours for each fix. After that, delivery is $39 to $55 an hour.

If you’re starting a new product instead, get a free project estimate before you pick the stack. It turns your brief into user stories, you confirm what is in scope, and every hour in the budget traces back to a story you kept, priced at our published $39-55 an hour.

When LIVETAG, a live shopping video platform, came back to us from another contractor, we kept the stack the previous team had chosen and put together a team that knew it. Then we refactored the web app and the iOS and Android apps. The LIVETAG case study shows how that went.

What we would do

1. Find out which PHP version and which framework version your app runs on.
2. If PHP is older than 8.2, plan the upgrade now. If it is 8.2, finish the move before 31 December 2026.
3. Keep a PHP system that works and has people who can maintain it. Connect new apps to it through an API.
4. For a new product with no PHP in the picture, build the back end in Node.js with TypeScript, unless your team already works in Laravel.
5. If nobody on your side understands the current code, start with an audit before you pay for new features.
6. Put upgrade work on the calendar every year, the same way you renew your domain.

FAQ

Is PHP outdated?

No. PHP runs 69.2% of websites whose server-side language W3Techs can detect, and new versions come out every year, with PHP 8.5 supported until the end of 2029. The risk sits in old PHP versions.

Is PHP secure enough for a business app?

Yes, on a supported version with reviewed code and proper handling of passwords and keys. Any PHP branch older than 8.2 no longer gets security fixes, and 8.2 stops getting them on 31 December 2026.

Should I choose PHP or Node.js for a new project?

If your team or your existing systems use PHP, stay with PHP. For a new product with no PHP around it, we use Node.js with TypeScript, so one language covers the front end and the back end.

How long is a PHP version supported?

Each PHP release branch gets two years of active support and then two years of security fixes only. Laravel releases get 18 months of bug fixes and 2 years of security fixes.