PHP and MySQL in 2026: Why I Still Build Client Sites With Them
Back to Blogs

PHP and MySQL in 2026: Why I Still Build Client Sites With Them

PHPMySQLWeb DevelopmentSmall Business

Every few months a client asks me some version of the same question: "Isn't PHP old? Shouldn't my site be built with something newer?" It is a fair question. Most of the tutorials and job posts people see online are about JavaScript frameworks, and PHP has a reputation from the early 2000s that it never fully shook off.

I still build most small business websites with PHP and MySQL in 2026, including this portfolio site. That is not because I don't know other tools. I use Node.js, React and Firebase when a project calls for them. I pick PHP and MySQL for a lot of client work because, for that kind of project, they are still the most practical choice. Here is my honest reasoning, and the cases where I choose something else.

What I mean by a PHP and MySQL website

When I say a PHP and MySQL website, I don't mean one huge file mixing HTML, SQL and business logic together, which is what a lot of older PHP code looked like. A typical setup for me today looks like this:

  • Pages that load fast, often plain HTML and CSS with a small amount of JavaScript
  • A few small PHP endpoints that return JSON, for things like the contact form, blog posts or portfolio items
  • A MySQL database for content the owner needs to change
  • A simple admin panel so the owner can edit that content without calling me

For bigger projects with user accounts, roles and lots of business rules, I use Laravel on top of the same PHP and MySQL base. Either way, the server side is boring in a good way.

Why I still choose PHP and MySQL

Hosting is cheap and available everywhere

Almost every shared hosting plan supports PHP and MySQL out of the box. A small business can host its site for a few dollars a month, with email, SSL and backups included in the same control panel. There is no server to configure, no Node process to keep alive and no separate database service to pay for.

For a local shop, clinic or service business, that matters. Their website is important, but it should not come with a monthly bill that keeps growing or a setup only one developer understands.

The client is not locked to me

PHP is one of the most widely used server languages on the web, so there are a lot of developers who can read and maintain it. If a client stops working with me, or I am busy, they can hand the project to someone else and that person can get going quickly.

I think about this a lot. A site built with a niche stack might be fun for me, but it can leave the owner stuck later. With PHP and MySQL on standard hosting, the files and the database are easy to back up, move and understand.

Modern PHP is not the PHP people remember

The PHP 8 releases changed a lot. There are proper types for function arguments and return values, enums, readonly properties, the match expression, named arguments and much clearer error messages. Performance also improved a lot compared to the PHP 5 days.

Combined with Composer for packages and a decent code editor, writing PHP today feels clean and predictable. Most of the bad reputation comes from old code and old habits, not from the language as it is now.

MySQL is enough for most small business data

A small business site stores a few kinds of data: blog posts, services, portfolio items, form enquiries, maybe bookings or products. That is a few hundred or a few thousand rows, not millions. MySQL handles that easily and has been doing it reliably for decades.

It also comes with phpMyAdmin on most hosts, which means the owner or another developer can look at the data directly if they ever need to.

How I keep a PHP site secure

PHP got a lot of its bad name from insecure code, so I am strict about a few habits on every project:

  1. Prepared statements for every query. I use PDO with placeholders, never user input pasted into SQL. This blocks SQL injection, which is still one of the most common ways small sites get hacked.
  2. Escaping output. Anything that came from a user or the database is escaped before it goes into the page, so nobody can inject scripts.
  3. Proper password storage. Admin passwords go through PHP's built-in password_hash() and password_verify(). No plain text and no old MD5 hashes.
  4. Secrets outside the public folder. Database passwords and API keys live in a config file the browser can't reach, and they never go into a Git repository.
  5. CSRF tokens and checks on admin forms. Every form that changes data checks a token, and file uploads are checked for type and size.
  6. Keeping PHP updated. I check which PHP version the host is running and move to a supported version when the old one reaches end of life.

Here is what a safe query looks like in practice. It is short, and it is the same pattern I use everywhere:

$stmt = $pdo->prepare('SELECT title, content FROM posts WHERE slug = ? AND status = ?');
$stmt->execute([$slug, 'published']);
$post = $stmt->fetch();

None of this is advanced. It is just discipline, and it is the difference between a PHP site that gets hacked and one that runs quietly for years.

When I don't use PHP and MySQL

PHP is not the answer to everything, and I tell clients that directly. I choose something else when:

  • The project is a real-time app. Live chat, live dashboards or anything where many users see updates instantly usually works better with Node.js or a service like Firebase.
  • It is mainly a web app, not a website. If the whole product is an interactive app with lots of screens and state, I use React or Next.js for the front end, and the back end depends on the project.
  • There is also a mobile app. If the same data feeds a mobile app, I plan the API first, and sometimes a hosted backend makes more sense than a PHP server.
  • The client mainly wants to sell products. For a straightforward online store, Shopify or WooCommerce is often cheaper and faster than building a custom shop.
  • The client's team already uses another stack. If they have developers who work in something else, I fit in with that.

What this means if you are hiring a developer

The technology behind your website matters less than most people think. What matters more is whether the site loads fast, is easy for you to update, is secure, and can be maintained by someone other than the person who built it.

When you talk to a developer, a few questions tell you a lot more than the name of the framework:

  • Where will the site be hosted, and what will that cost each year?
  • Can I edit my own content, and how?
  • Who has access to the files and the database, and will I get copies?
  • If you are not available, could another developer take over easily?
  • How are backups and updates handled after launch?

If the answers are clear and sensible, the stack is probably fine, whether it is PHP, JavaScript or something else.

My take

I keep using PHP and MySQL because they let me build sites that are fast, affordable to host and easy to hand over. My clients don't care what language their contact form is written in. They care that enquiries arrive, the site doesn't break, and they can change their prices without waiting for me.

If you are not sure which approach fits your project, send me a message with a short description of what you need. I will tell you honestly what I would use and why, even if it is not PHP.