My PHP + MySQL Stack for Small Business Software in 2026

Ali Raza — Wed, 21 Oct 2026 12:45:19 +0000

Everyone asks why I still build with PHP and MySQL in 2026. The answer is simple: my clients are small businesses, and small businesses need software that is cheap to host, easy to maintain, and fast to build. For that job, PHP + MySQL is still hard to beat.

I build lead management tools, courier tracking systems, agency management software, and e-commerce stores with this stack. Here is exactly how I set things up.

1. Plain PHP, organized like a framework

I don't reach for Laravel on every project. For a small business tool with 10–20 pages, a full framework adds deployment complexity the client will never benefit from. Instead I use plain PHP with a strict folder structure:

/public        → the only web-accessible folder (index.php front controller)
/src           → controllers, models, helpers
/templates     → plain PHP view files, no template engine
/config        → database credentials, constants (outside /public)
/uploads       → user files, blocked from executing PHP via .htaccess

One rule I never break: nothing outside /public is reachable from the web. config.php with database credentials sits one level above the document root. On cheap shared hosting this single habit prevents the most common credential leaks.

2. PDO with prepared statements — no exceptions

Every database query goes through PDO with prepared statements. No string concatenation, ever. It takes five extra seconds per query and eliminates SQL injection completely:

$stmt = $pdo->prepare("SELECT * FROM orders WHERE client_id = ? AND status = ?");
$stmt->execute([$clientId, $status]);
$orders = $stmt->fetchAll(PDO::FETCH_ASSOC);

I also keep one db.php that creates a single PDO instance with ERRMODE_EXCEPTION and utf8mb4 charset. Every page includes it. Consistent, boring, reliable.

3. One shared hosting account per client

Small businesses in my market already pay for shared hosting (usually a few dollars a month). My software runs fine on it — no VPS, no Docker, no monthly server bill the client doesn't understand. Deployment is FTP or the host's file manager: upload, import the .sql schema, done.

This is a business decision, not a technical limitation. When a client outgrows shared hosting, we migrate. Most never need to.

4. Server-rendered pages, minimal JavaScript

I render HTML on the server and use vanilla JavaScript only where the page genuinely needs interactivity (live search, form validation, print views). No build step, no npm, no 3MB of JavaScript for a dashboard.

The result: admin panels that load in under a second on a phone with a weak connection. My clients notice this. Their staff uses these tools on mobile data all day.

5. Backups the client can understand

Every system I ship has a one-click database backup in the admin panel that downloads a .sql file. I also tell the client to download one monthly. Fancy automated backup pipelines are great, but a client who can restore their own data from a file they downloaded is better.

What I'd do differently at scale

If a project needs real-time features, background jobs, or an API consumed by mobile apps, I switch to Laravel or Node. The plain-PHP approach is a deliberate choice for a specific client profile — not a religion.

The stack is boring on purpose. Boring means the client's nephew can find a developer to maintain it, the hosting costs almost nothing, and nothing breaks at 2 AM. For small business software, that's the whole job.

I'm Ali Raza, a Full Stack Web Developer from Pakistan. I build custom websites, e-commerce stores, and business software for small businesses. Portfolio · GitHub · LinkedIn