LAMP Is Still Enough for Most Web Projects

I keep seeing this idea floating around that building with PHP, MySQL, Apache, and server-rendered pages is somehow unserious now.

Like if your project doesn’t have a modern JavaScript frontend, a serverless backend, a typed API layer, an edge deployment story, and a pipeline with more moving parts than the actual app, you’re doing it wrong.

I don’t really buy that.

For most professional, part-time, solo, and hobby web developers, LAMP still does the job. Most of them are building normal web things, not Google Docs, Figma, Slack, Uber, or Netflix.

This isn’t nostalgia, and I’m not trying to pretend PHP is perfect, Apache is romantic, or MySQL has a tiny little halo hovering over it. Modern stacks exist for real reasons. If you’re building something with realtime collaboration, complex frontend state, mobile-app-style behaviour, huge scale, or a large engineering team, then yes, you probably want tools shaped for that job.

But a lot of web projects are still pages, forms, users, database records, admin screens, uploads, emails, reports, and scheduled jobs.

That is not some weird old-web corner case. It is a huge amount of everyday web work, and LAMP is still very good at it.

---

Most web projects are still normal web projects

A lot of web development advice seems to assume everyone is building the next big SaaS platform with millions of users and a frontend team arguing about state management in a glass meeting room.

Some people are doing that, of course.

Most people aren’t.

Most people are building much more ordinary things: a business website with a few custom forms, a directory, a private admin area, a booking system, a reporting dashboard, a customer portal, a niche app with accounts and database records, a WordPress plugin, an import tool, or a small internal workflow app that saves someone a few hours a week and will never need Kubernetes unless someone has made a very strange life choice.

Those projects aren’t necessarily trivial. A decent booking system can have awkward rules. A customer portal still needs proper permissions. A reporting dashboard still needs good queries and clear output. A directory might need moderation, search, admin screens, scheduled imports, and some thought around structure.

Normal web projects can still be real work.

But they don’t need to start life with startup architecture, three services, a decoupled frontend, a message queue, and a deployment setup that requires a ceremonial robe and a small offering to the YAML gods.

Most apps are still basically pages, forms, users, database records, admin screens, emails, uploads, and scheduled jobs.

LAMP fits that shape because it was built around straightforward request-and-response web work. The browser asks for something, the server handles it, PHP builds a response, MySQL stores the data, and the user gets a page they can use.

It is not fashionable, but there is a lot to be said for a stack where the basic path through the application is still understandable.

---

LAMP matches the shape of normal web work

The basic LAMP model is almost painfully direct.

Apache receives a request, PHP does the application work, MySQL stores and retrieves the data, and HTML/CSS render the interface. Cron handles the boring scheduled jobs in the background.

That might sound old-fashioned, but when you’re building alone or working on something part-time after a day of dealing with other people’s nonsense, that kind of clarity starts to look less like a limitation and more like a feature.

There’s something powerful about a stack where you can understand the whole trip from URL to database query to rendered page.

You can open the files, inspect the database, change a template, refresh the browser, and see what happened. You’re not always chasing a build step, a hydration issue, a mystery environment variable, a stale cache, or a toolchain that has quietly gone off to sulk in a corner.

PHP is easy to deploy. Apache is everywhere. MySQL is well understood. Cheap hosting supports the whole thing. Cron is enough for a surprising number of background jobs. Server-rendered pages are still perfectly fine for many interfaces.

And you can still add JavaScript where it helps, instead of making JavaScript the centre of the universe by default.

Using LAMP doesn’t mean pretending JavaScript doesn’t exist. Sometimes a bit of vanilla JS, a small interactive widget, or a lightweight library is enough. The page can still be mostly server-rendered, the app can still be simple, and the work can stay focused on what the thing is meant to do rather than how impressive the stack sounds when you describe it.

---

Boring stacks are often good stacks

There’s a weird thing in tech where “boring” gets treated like a failure.

That’s odd, because boring is often exactly what you want when you’re trying to build and maintain something useful.

Boring means the docs exist. Boring means the hosting is cheap. Boring means the error message has probably been seen by some poor soul on a forum in 2011. Boring means you can come back to the project three months later and still vaguely understand what past-you was thinking, even if past-you was tired, over-caffeinated, and making optimistic comments like:

// temporary fix

That is especially useful for solo builders, because the main problem for most solo projects is not:

How do I scale this to ten million users?

The problem is usually more ordinary and, frankly, more annoying:

Can I build version one, deploy it, fix it when it breaks, afford to host it, understand it next month, and keep improving it without turning the whole thing into a second unpaid job that resents me?

A stack that helps with those questions is doing something useful, even if it doesn’t look impressive in a conference talk.

Nobody is going to make a dramatic launch video about “a form posting to a PHP script,” but a lot of useful software is still built from boring pieces that work together in boring ways.

For small projects, boring can be a perfectly sensible technical choice.

---

The edge cases are real, but they are edge cases

There are plenty of projects where plain LAMP is not the best starting point.

If you’re building Google Docs-style collaboration, Figma-style design tools, Slack-style realtime messaging, Uber-style live location systems, Netflix-scale video delivery, a huge SPA with complex state, or a distributed job pipeline with lots of moving parts, then yes, you should probably reach for tools designed around those problems.

The issue is not that modern stacks solve imaginary problems.

The issue is that they often get treated as the default solution for projects that don’t actually have those problems yet, and may never have them.

If you are building Figma, use Figma-shaped tools. Nobody wants collaborative vector editing powered by vibes and a lonely functions.php file.

But if you’re building a small directory, a niche dashboard, a content site, a private admin app, or a simple SaaS with accounts and database records, you probably don’t need to start with Figma’s level of architecture.

You need something you can build, deploy, understand, and maintain.

For a lot of small web projects, that matters more than whether the stack looks modern from the outside.

---

Modern stack advice often comes from the wrong world

A lot of modern web advice comes from a very specific world: venture-backed startups, big tech engineering blogs, frontend-heavy SaaS companies, teams with dedicated DevOps people, products with huge traffic, and companies hiring specialist engineers to work on narrow slices of a much larger system.

That advice isn’t automatically wrong.

It’s often very good advice for that world.

The trouble starts when it gets handed to a solo builder making a niche tool on weekends.

A large engineering team has different problems. They need consistency across many developers. They need deployment workflows that stop one person from setting the building on fire. They need frontend architecture because the frontend may be a whole product in itself. They need observability, automated testing, service boundaries, and all the other grown-up machinery that keeps big systems from becoming expensive soup.

A solo builder usually needs something else: momentum, a clear mental model, fewer places for bugs to hide, and a stack they can actually deploy without losing a weekend to permissions, build tools, and one mysterious environment variable named something like:

PUBLIC_PRIVATE_CLIENT_SECRET

There is a point where modern architecture stops being helpful and starts becoming a tax.

If your little web app hasn’t earned that tax yet, it’s worth asking why you’re paying it up front.

---

Simple does not mean amateur

This is the bit that really annoys me.

Simple stacks often get treated as unserious, as if a PHP/MySQL app is automatically a toy and a modern JavaScript stack is automatically professional.

That’s nonsense, but it is a surprisingly common vibe.

A badly built React app is still bad. A badly designed serverless setup is still bad. A bloated microservice architecture wrapped around a half-baked product idea is still a half-baked product idea, just now with more invoices.

Meanwhile, a well-built LAMP app can be fast, reliable, maintainable, and useful. It can have clear routes, sensible templates, proper validation, prepared statements, decent permissions, background jobs, logging, backups, and a deployment process that doesn’t require interpretive dance.

Professionalism is not about whether the stack is fashionable.

It is whether the thing works, whether it can be maintained, whether it is secure enough for the job, whether it solves the user’s problem, and whether the developer can keep it alive without slowly becoming a haunted version of themselves.

A simple, boring, understandable stack can still be a professional choice if it solves the problem and doesn’t make maintenance miserable.

---

The best stack is the one that fits the actual job

The goal is not to pick the oldest stack, or the newest stack, or the stack that makes people on social media nod approvingly.

The goal is to match the stack to the job.

If the app is mostly server-rendered pages, forms, user accounts, database queries, uploads, emails, admin tools, and scheduled imports, LAMP is still a very reasonable choice.

If the app needs realtime collaboration, offline-first behaviour, complex browser-side state, mobile-app-style interactions, or large-scale distributed processing, then sure, reach for something else.

The problem isn’t modern tooling itself.

The problem is defaulting to complexity before the project has asked for it.

A lot of small web projects die long before they get enough users to justify the architecture they started with. Not because the idea was terrible, but because the builder drowned in setup, rewrites, dependencies, deployment friction, and the constant feeling that they were doing it wrong.

Sometimes the practical move is to start with the boring thing that works, get the app online, make the core action useful, and let real usage tell you where the limits are.

You can always upgrade the parts that actually need upgrading later.

That is usually easier than hauling around a complicated architecture designed for a fantasy version of the product.

---

You can always add complexity later

One of the best arguments for a simple stack is that it doesn’t lock you into staying simple forever.

You can start with server-rendered PHP pages and add JavaScript where the interface needs it. You can start with cron and move specific jobs to a queue when cron stops being enough. You can start with one database and improve the schema as the product becomes clearer. You can move to a different deployment setup when the old one starts creaking under real demand.

That’s not a failure of planning.

It’s just how a lot of useful software grows.

Architecture should respond to pressure rather than cosplay a future version of the product that may never exist.

There’s a big difference between planning sensibly and overbuilding because some tutorial made you feel underdressed.

For a lot of small projects, the right first version is boring on purpose: one app, one database, one server, clear files, clear routes, clear admin screens, scheduled jobs, backups, logs, and a sensible way to deploy changes.

Get that working first, because you’ll learn more from a small working app than from a beautifully architected fantasy that never ships.

---

LAMP also plays nicely with AI coding tools

This is one part of the conversation that doesn’t get enough attention.

AI coding assistants can be very useful with simple stacks because the project shape is easier to describe.

You can tell the tool: this is a PHP/MySQL app, these are the files, this is the route, this is the database table, this is the form, and this is the expected behaviour.

That kind of constraint helps because the AI has fewer layers to misunderstand and fewer excuses to wander off into some grand architectural adventure nobody asked for.

The more abstract and distributed the system becomes, the more room there is for the AI to make confident nonsense decisions across layers it doesn’t fully understand. It might still help, but you have to supervise it more carefully.

With a simple app, you can often keep the AI on a short lead. Ask it for one controller, one view, one SQL query, one validation rule, one admin screen, or one cron script.

Ask for full replacement files rather than vague snippets.

Make it solve the specific problem in front of it, not redesign the whole application because it got excited.

That is where old-web simplicity and new-world tools can work nicely together.

Not because AI makes everything easy, but because simple architecture gives both you and the tool fewer places to get lost.

---

The web got complicated, but most projects didn’t

The modern web has real complexity because some apps have genuinely complex requirements.

I’m not arguing against that.

If your product needs realtime collaboration, mobile-app-style interactions, huge frontend state, distributed infrastructure, or serious scaling work, then build for that reality.

But not every website is an app. Not every app is a platform. Not every product needs an event-driven architecture. Not every admin screen needs a frontend framework. Not every side project needs a deployment pipeline that looks like airport logistics.

Most projects are still normal web projects, and normal web projects deserve tools that fit them.

LAMP is not glamorous. It won’t make you feel like you’re standing on the bleeding edge of software engineering with the wind dramatically hitting your hoodie.

It will, however, let you build database-backed websites, admin panels, directories, reporting tools, customer portals, simple SaaS apps, content sites, import scripts, dashboards, and small utilities that people can actually use.

For a lot of builders, that is the work:

Build the useful thing, get it online, keep it understandable, and only add complexity when the project has actually earned it.

That’s not nostalgia.

That’s just a sensible way to avoid turning a small web project into a shrine to unnecessary suffering.