Which tech stack for which project

Clients ask which technology we will use surprisingly early, usually in the first conversation. It is a reasonable question and it is almost always the wrong one to start with, because for most projects several answers are correct and the choice is settled by things that have nothing to do with the technology.

Here is what actually decides it.

Where it has to run

This is the constraint people never see coming, and it is the one that eliminates options fastest.

A PHP application runs on ordinary shared hosting. Every budget host on earth supports it, it costs very little a month, and it needs no special setup. A modern JavaScript application needs a Node process running continuously, which is a different and less universally available kind of hosting. Plenty of cheap plans do not offer it at all, and the ones that do put it behind more configuration.

So if the hosting is fixed, or the budget for hosting is small and permanent, that decides a great deal before anyone discusses frameworks. This is not a hypothetical concern. It is the single most common reason a technically sound choice turns out to be the wrong one.

Who maintains it after we leave

The second question, and it matters more than any benchmark.

If your own team will take the project over, build it in what your team already knows. A marginally better framework that nobody in your building can read is worse than an ordinary one they can. If nobody is taking it over, the question becomes how easily you could replace us, which argues for boring, widely used technology over anything clever.

Either way the answer is about people, not performance.

What it actually has to do

Only third does the work itself start narrowing things, and usually less than you would expect. Most business software is forms, records, permissions and reports. Almost everything can do that competently. The technology only becomes decisive at the edges: heavy real-time behaviour, unusual performance requirements, hardware access, very large volumes of data.

If your project is not at one of those edges, and most are not, then arguments about which framework is fastest are arguments about a difference your users will never perceive.

What we reach for, and when

Our web work runs on two tracks, and the split follows the hosting question above.

Laravel and PHP take anything that has to live on standard hosting, anything with a substantial admin side, and anything where the client wants a cheap, boring, permanent home for it. PHP carries a poor reputation earned two decades ago and largely undeserved now. Laravel in particular hands you authentication, permissions, an admin layer and database migrations without assembling them yourself, which is exactly where a business application spends most of its budget.

Next.js with React goes where the interface is the product. Anything highly interactive, anything with real state to manage in the browser, anything where page speed and search visibility both matter. This site runs on it, and so does our dashboard example build, because a chart with a crosshair and keyboard navigation is precisely the kind of thing this stack exists for and precisely the kind that turns painful without it.

We write TypeScript rather than plain JavaScript on anything we expect to still be editing next year. The value is not fewer bugs on day one. It is that a change six months later tells you immediately what else it just broke.

Styling goes through Tailwind for one unglamorous reason: it keeps the design decisions in the markup where you can see them, rather than in a stylesheet that grows another layer of overrides every time somebody is in a hurry.

Mobile work goes to Flutter when an app is genuinely warranted. One codebase produces both iOS and Android, which roughly halves the build and, more to the point, halves every change you make for the rest of the app's life. Native earns its cost when you need deep platform integration or the last increment of polish. For most business apps it is a way to pay twice.

For data it is PostgreSQL or MySQL, and at the scale most projects run at this genuinely does not matter. Take whichever your hosting provides. Postgres is the better database when the choice is open and the data has real structure to it.

C++ appears where the work is desktop software or carries performance requirements a web stack cannot meet. It is a specialist answer to a specialist question and should never be the answer to an ordinary one.

Docker shows up when a project has more than one moving part, or when the difference between our machine and the server has started costing real time.

The question worth asking instead

Rather than which technology, ask what happens in three years.

Can you still hire someone who knows this. Is the framework still maintained. If you want to move hosts, can you. If you want to move developers, how much of what we built is standard and how much is ours. Those answers tell you far more about what you are buying than the name of a framework does.

Any studio that answers "which stack" with the same word every time, regardless of what you described, is telling you about their staffing rather than your project.