Fast, secure web applications and shops on current PHP, plus the unglamorous work of getting an old codebase onto a version that still receives security updates.
PHP runs a large share of the web, and a large share of that is stuck on a version nobody patches any more.
Moving from an unsupported PHP is usually the highest-value security work available to you, and it's rarely as bad as feared.
Recent versions are several times faster than the ones most legacy sites still run. Upgrading often removes the need for bigger servers.
Product catalogues, checkout and integrations, either on a framework or on the shop platform you already use.
Modest hosting requirements, which keeps running costs low and options open.
Standard PHP, a standard database and a documented deploy. Any competent PHP developer can pick it up, which is the point.
More developers write PHP than almost anything else, so replacing us — or adding to us — is a hiring problem rather than a rescue.
Catalogues, checkout, payments, VAT, invoicing and shipping, either on a framework or on the shop platform you already run. Most of what a shop needs already exists in PHP and has been tested by a very large number of people.
A login, an account, documents, invoices and whatever your customers currently phone you to ask for. This is the work that quietly removes the most hours from a week.
The system that runs your operation and exists nowhere off the shelf: scheduling, stock, approvals, reporting. Usually the highest-value software a business owns and the least glamorous to describe.
A documented interface your mobile app, your shop or a partner integrates against, with authentication, rate limits and versioning handled rather than assumed.
Moving off an end-of-life PHP without a rewrite. We inventory what breaks, fix it in order of risk, and keep the old and new running side by side until the new one has proven itself.
Most of our PHP work. It starts with a written assessment of the code, the data and the deployment, which is yours whether or not you continue with us.
Written for someone deciding, not for someone who already knows. Skip it if you do.
A programming language made for building websites, and one of the few that has done nothing else for thirty years. When you open a page, PHP is the part that runs on the server: it reads the database, works out what you should see, and hands the browser finished HTML. You never see it and you never install anything. Roughly three quarters of the websites whose language can be identified run on it, WordPress, Wikipedia and a large share of online shops among them.
It's cheap to host, it runs on essentially any server, and it has thirty years of solved problems behind it: payments, invoices, VAT, shipping, PDFs, e-mail. For most business software the hard part isn't the language, it's the hundred small things a real system needs, and in PHP most of those already exist and have been tested by a very large number of people. That's also why finding somebody to take over a PHP project later is easier than for almost anything else.
It fits catalogues, shops, booking systems, portals, invoicing, internal tools and anything with a database behind a login. It's not the right answer for something that has to hold thousands of live connections at once, like a chat or a trading screen, and it's not what you would reach for to build a mobile app. We'll say so when that's the case rather than sell you the thing we happen to be on.
PHP has changed enormously and most of its reputation comes from versions nobody should still be running. Current PHP is several times faster than PHP 5 and stricter about the mistakes that used to cause security problems. A version past its end of life gets no security patches at all, so known holes simply stay open. If you're on one, moving off it's usually the highest-value work available to you, and it's rarely as bad as feared.
Most new PHP work sits on Laravel or Symfony, which supply the routing, the database layer, the queues and the security defaults so nobody rebuilds them badly. Plenty of what we inherit uses no framework at all, which is normal for older systems and not a reason to rewrite: we work in what is there, add tests around the parts that earn money, and introduce structure only where it pays for itself.
WordPress, which is a large share of the web on its own, along with Wikipedia, Slack’s original back end, Mailchimp and a great many banking and government systems that nobody advertises. It's not a language that quietly disappeared; it's one that stopped being talked about because it works.
Anything before PHP 8.1 receives no security fixes at all today. Known holes simply stay open, and an insurer or an enterprise customer will eventually ask.
Old PHP is several times slower than current PHP. Teams routinely buy bigger machines to cover it, then find the upgrade removes the need for them.
If a single developer is the only route into your system, the version isn't your biggest problem. Writing down what is there is the first job, and it's one you keep.
Once a version stops receiving security updates, known vulnerabilities simply stay open. It's normally the first thing we recommend fixing, ahead of any new feature.
Yes, and with codebases on no framework at all, which is common in older systems. The approach is the same: understand it, test the critical paths, then change it in steps.
Usually not. Modern PHP is fast and well supported, and a rewrite risks losing years of business rules nobody wrote down. We rewrite when the language is genuinely the problem, which is rarer than people expect.
It depends entirely on scope, and anyone quoting before understanding yours is guessing. What we can promise is the shape: a fixed price for a first version we have both scoped, then a rate for what follows. The first conversation is free and thirty minutes is usually enough to tell you whether we're the right people.
Most of our PHP work is exactly that. We start by reading the code, the database and the deployment, then give you a written assessment of what is solid, what is risky and what it would cost to fix each. You own that document whether or not you continue with us.
It's yours in full, in your own repository, with the build that produces it and the instructions to run it. We hand over the hosting account too. Leaving us should be a decision you can take calmly.
The version most people picture is. Current PHP is typed, several times faster and stricter about the mistakes that gave it its reputation. The language moved on; the opinion largely has not.
A small site is days. A large one with custom extensions is weeks, done in stages with the old and new running side by side. We give you the inventory and the estimate before you commit to any of it.
A few lines are enough to start. You get a reply within two working days.
