Modern PHP and how we pick the stack
Why so much of the web still runs on PHP
PHP was designed for one job, answering web requests, and it is still very good at it. Each request starts clean, does its work and ends, so a memory leak or a crashed script affects one page view and not the whole server. Almost every hosting company supports it, which keeps running costs low and avoids lock-in. WordPress, Moodle, Laravel and Magento are all written in PHP, so the pool of developers who could take over your project is large. That last point matters more than benchmarks, because software outlives the team that wrote it.
What changed in the language
If your picture of PHP comes from code written ten or fifteen years ago, the current language will surprise you. Functions and properties declare their types. Enums replace magic strings. Readonly properties and constructor promotion remove pages of boilerplate. Mistakes that used to pass as silent warnings now throw errors. Around the language, Composer manages dependencies, the PSR standards mean libraries from different authors fit together, and static analyzers such as PHPStan and Psalm read the whole codebase and report bugs without running it. We use all of this by default. It is what keeps a PHP project cheap to change in its fifth year.
Plain PHP, a framework or WordPress
This is the decision that shapes cost most, and we make it with you before quoting.
- Plain PHP with a router and a few libraries suits small tools with a long life: a calculator, a booking form, a webhook receiver, an internal report. Few dependencies means few forced upgrades.
- Laravel suits applications with users, roles, queues, notifications and an API. You accept some overhead and get a great deal ready-made.
- CodeIgniter suits teams that want MVC structure with a small footprint, modest hosting, or an existing CodeIgniter codebase worth keeping.
- WordPress suits sites where editors publish daily and the custom logic is a thin layer on top. Once the custom logic becomes the product, it belongs in an application.
What we find in inherited code, and how we avoid it
Most troubled PHP projects we take over share the same faults: SQL built by gluing strings together, business rules buried in templates, no version control, and passwords committed next to the code. These are habits of the people who wrote it, and the language is not to blame. Our builds keep configuration in environment files, send every query through prepared statements, escape output in the template layer and put rules in classes that can be tested without a browser. A continuous integration run checks style, static analysis and tests on every push, so the standard does not depend on who is on the project that week.
Hosting is part of the design
Shared hosting, a single VPS and an autoscaling cloud setup call for different choices about sessions, file uploads, background work and caching. We ask where the application will live before we design it. A tool that must run on shared hosting gets cron in place of queue workers. One that will sit behind a load balancer gets shared session storage and object storage for uploads from the first commit.
