Choosing your stack: when to use what

Ask ten developers what stack to use for a new project and you will get ten different answers, and most of them will trace back to whatever that person shipped last, or whatever they saw discussed online last week. That is not a knock on anyone. It is just how habit and hype both work, and neither one is a good tie-breaker for a decision that shapes how fast you can ship, what you pay in hosting and maintenance, and how easy the project is for someone else, including future you, to pick back up. This walks through what a stack actually is, the criteria that actually move the needle, the case for picking proven technology over the newest thing, and a concrete starting point for four common kinds of projects.

What a "stack" actually is

A stack is the set of technology layers a project is built on. Most conversations about "the stack" collapse into four pieces, and knowing what each one actually does is the first step to picking correctly instead of by reflex.

• Frontend: what runs in the visitor's browser, the HTML, CSS, and JavaScript (often through a library like React) that renders what someone actually sees and clicks.
• Backend: code that runs on a server, handles requests, and enforces rules a browser cannot be trusted to enforce on its own, like checking a password or a payment.
• Database: where data that needs to persist between visits, and between different visitors, actually lives, so it survives after the request that created it finishes.
• Hosting: where the code and data physically run, and what handles traffic, uptime, and deploys once the project is live.

The part people skip past: not every project needs all four. A marketing page with no accounts and nothing that changes per visitor is frontend and hosting, full stop, no backend and no database, and nothing on either of those to secure or patch later. MDN's own framing of the difference is useful here: "a static site is one that returns the same hard coded content from the server whenever a particular resource is requested," while "a dynamic site is one that can generate and return content based on the specific request URL and data."¹ If your project fits the static description, a database and a backend framework are not a head start, they are unused surface area sitting there waiting to need patching. A one-off script that reformats a spreadsheet does not have a "frontend" in the browser sense at all. Bolting on layers a project does not need is one of the most common ways a simple task turns into an infrastructure project nobody asked for.

The criteria that actually matter

Once you know which layers a project needs, the actual choice inside each layer comes down to a handful of questions, roughly in this order of importance.

• What you are building: a portfolio page and a real-time multiplayer app do not belong on the same stack, which sounds obvious until deadline pressure makes "the modern thing" and "the right thing" start to look like the same choice.
• What you, or your team, already know: shipping in something you already know how to operate beats a theoretically better tool you have to learn under a deadline. The "best" tool on paper loses constantly to the boring tool someone on the team can actually run at 11pm when something breaks.
• Docs, community, and longevity: can you find the answer to your question in five minutes, or are you the first person to hit this exact bug? A framework with thin documentation and a small community turns every unusual problem into original research instead of a search away.
• Hosting and ops burden: what does this cost to run, and who is on call when it breaks? A statically hosted site has close to zero ongoing ops burden. A stack with a database, background jobs, and a cache has real operational surface area that someone has to own for the life of the project.
• Team size: solo and team projects disagree on what counts as "simple." A tool that is simple for one person holding the whole system in their head can be genuinely hard for a five-person team to onboard into, and a heavier, more structured framework that feels like overkill solo can be exactly what keeps five people from stepping on each other's changes.

The case for boring, proven technology

Dan McKinley's widely cited engineering essay "Choose Boring Technology" gives this instinct a name: innovation tokens. The framing is that a team only has a small, fixed number of genuinely novel technology choices it can afford to make and still ship. In his words, "let's say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while."² Every unfamiliar database, unfamiliar framework, or unfamiliar deploy pipeline spends one of those tokens, whether or not the choice was actually necessary for what the project needed to do.

Boring does not mean bad. It means the tradeoffs are already mapped by thousands of people who hit the same failure modes before you did. McKinley's own description of mature tools: "the capabilities of these things are well understood. But more importantly, their failure modes are well understood."² New technology carries a different, harder-to-plan-for kind of risk, not because it is worse, but because nobody has finished discovering what breaks yet: "for shiny new technology the magnitude of unknown unknowns is significantly larger, and this is important."²

The essay's sharpest line reframes "best tool for the job" thinking entirely: "your job is keeping the company in business... and the 'best' tool is the one that occupies the 'least worst' position for as many of your problems as possible."² Picking the locally best tool for every individual piece of a project adds up to a system nobody fully understands, running on five things the team has to separately keep current, patched, and staffed for. Picking boring defaults everywhere except the one part that is genuinely new keeps that list short.

A default by project type

None of this tells you the one correct stack, because there is not one. What follows is a sensible starting point for four common shapes of project, not a rule. Treat the "why" column as the reasoning to check against your own project, not as a verdict.

These are starting points, not laws, and real projects blend categories constantly. A content site with one interactive comment widget does not need a full app framework bolted on for that single feature, a small script that runs on a schedule and needs to remember what it did last time might genuinely need a lightweight database, even though the "script" row above usually skips one. Read the "why" column, check it against what your project actually does, and diverge on purpose when it does not fit.

A short checklist before you commit

Before you scaffold anything, work through these in order. Most stack regrets trace back to skipping one of them, usually the second or the fourth.

There is rarely one right answer

Plenty of teams build the same kind of app successfully on completely different stacks, and plenty of stacks that look identical on paper produce very different outcomes depending on who is running them. The goal here was never to hand you the one correct answer, because there is not one to hand you. The goal is avoiding the two failure modes that actually cause regret: picking by habit alone, never once checking whether last project's default still fits this one, and picking by hype alone, chasing whatever framework is loudest this month without asking what problem it actually solves for you. Between those two, almost any deliberately reasoned choice holds up fine.