You're being asked to judge a stack you can't evaluate

Frontend is what loads. Backend is what decides.

Almost every quote splits the work into two halves and calls them the frontend and the backend. It isn't jargon for its own sake. The words say where the code physically runs, and that decides what's cheap to change, what's safe, and who can break it.

The frontend runs on your visitor's device. Their phone, their laptop, inside their browser. It's the layout, the type, the buttons, the panel that slides open when they tap it. Once it's been sent to them it's theirs, running on hardware you don't control.

The backend runs on a computer you rent, somewhere else. It holds the rules and the records. Who's allowed to see this. What the price actually is. Whether that booking is confirmed. Anything that has to still be true tomorrow lives here.

A price shown on a page is frontend. A price charged to a card is backend. A form that turns red when the email address looks wrong is frontend, and it's a courtesy. The check that actually refuses the bad address is backend, and it's the one that counts.

You don't need this to run your business. You need it to read a quote. Moving a button is a frontend change and it's usually cheap. Changing what happens when a customer cancels is a backend change, and it can touch records, emails and money in one go. That's normally why two quotes disagree wildly about one small-sounding feature.

Three more words you'll meet in a quote

A database, hosting and a CMS turn up in nearly every proposal, get priced separately, and often end up owned by different people. Each one decides something different about what your team can do without phoning a developer.

A database is where the records sit when nobody's looking at them. Customers, orders, bookings. It's the least interesting part of a build and the only part you can't recreate by building the thing again, so the question worth asking isn't which database. It's who holds a copy, and how old the newest one is.

Hosting is the computer the backend runs on and the bill that arrives for it. You rent a managed service that keeps the thing running and charges you by use, or you rent servers and somebody on your side keeps them alive. That's a staffing question wearing a technical costume, and it usually gets decided as though it were the other way round.

A CMS, or content management system, is the screen your own team signs into to change words and pictures without asking a developer. It's the layer most often left out of a quote and most often missed afterwards. Without one, updating a phone number is a small software release. That's fine right up until the week you need three changes and the only person who can make them is away.

None of the three decides whether the build works. They decide what ordinary work costs you for years afterwards.

Nobody picks these one at a time

You won't be asked to choose a frontend, then a database, then a host. They arrive as a set, and the set is what people mean when they say a stack. The pieces have to agree with each other, so settling one narrows the rest.

What varies between one stack and another isn't really the technology. It's how much of it you're renting. Rent nearly all of it and you get a platform that already has the frontend, the backend, the database and the editing screen, and you bring the content and the design. Build more of it and you get something shaped around whatever makes your business different.

The trade doesn't move. The more you rent, the faster you launch and the sooner you hit something the platform won't do. The more you build, the better it fits and the more it depends on somebody still being around to look after it in two years. Neither end is safer in the abstract. One of them is safer for you, and the questions further down are how you find out which.

We don't sell a stack

The tools get chosen per project, after the problem is defined and the scope is written down. That order matters. A stack picked before anyone knows what the thing has to do is a preference, not a decision.

So this isn't a capability parade. Each page here takes one name you might find in a proposal and sets out what it's for, what it's genuinely good at, and where it stops being the right answer. That last part is the useful bit, and it's what most technology pages leave out.

How the choice actually gets made

Four questions do most of the work, and none of them are about the technology itself. What does this have to do in three years, not this quarter. Who maintains it once we hand it over, and can they. What are you already paying for that could carry this. And what does it cost you to leave, if the answer turns out to be wrong.

The second one decides more builds than the other three together. Software nobody on your side can operate is software you'll be paying someone to rebuild, and that bill arrives long after the launch everyone was happy with.

Answer them honestly and the shortlist is usually two options, sometimes one. Most arguments that look like technology arguments are disagreements about one of those questions that nobody has said out loud.

Be careful with anyone who leads with their stack

Partners push what they already know. That isn't dishonesty, it's gravity, and it's the most common reason a business ends up on a platform that doesn't fit it. If the tool shows up in the conversation before your problem does, that's the tell.

The bigger risk isn't picking the wrong technology, though. It's leaving the decision unmade while the business waits, until you're choosing against a deadline instead of with time. Almost any reasonable stack, picked on purpose and maintained, beats the perfect one picked in a panic.