What Is a Tech Stack? Explained Without Jargon

A tech stack is the set of technologies a piece of software is built and run on: the programming language, the framework, the database, the hosting and the third-party services that tie it all together. If you're wondering what a tech stack is because a developer just sent you a proposal full of names like Laravel, React and PostgreSQL, think of it as the toolbox behind your product. That choice decides what it costs to build, what it costs to run, and how easily someone else can take over the code later.

Below I walk through each layer using one concrete example, a booking system for a group of physiotherapy clinics. I work in Laravel and React myself, so those are the examples I reach for, but the principles apply to any stack.

The short answer: the layers of a tech stack

It's called a stack because the layers sit on top of each other: the interface talks to the backend, the backend talks to the database, and the whole thing runs on a server. Each layer can be built with different technologies, and your particular combination is your stack. The choice gets made early in a project, and you can see where it fits in my guide to the software development process from idea to launch.

Following one booking through the stack

Picture a patient booking a Tuesday morning appointment with her physiotherapist. Between opening the page and getting a confirmation text, every layer does its part:

1. She opens the booking page on her phone. Everything she sees, the calendar, the buttons, the list of therapists, is the frontend, running in her browser.
2. She picks Tuesday at 10:00 and taps "Book". The frontend sends a request to the backend, the program running on the server. This is where the rules live: is the slot still free, is the therapist on a break, does the clinic require payment upfront?
3. The backend saves the booking in the database, which is the system's memory. It keeps everything, even when the server restarts.
4. If the clinic takes payment upfront, the backend asks a payment provider such as Stripe to charge the card. Card numbers never touch the clinic's own system.
5. The backend puts two jobs in a queue: a confirmation now and an SMS reminder the day before. The queue means she isn't left waiting while messages go out.
6. Each evening, the system sends the day's payments to the clinic's accounting software through an API, the door other systems use to talk to it.
7. All of it runs on a server with a hosting provider, ideally inside the EU, with backups and monitoring that alerts someone if anything goes down.

The patient sees one app. Behind it are five or six layers that were each chosen, built and now need looking after. That's why your tech stack matters to you even if you never read a line of code.

LAMP, MERN, TALL and "full-stack": the jargon decoded

Developers love abbreviating stacks. These are the three you'll run into most:

• LAMP: Linux, Apache, MySQL and PHP. The classic combination behind a huge number of websites, including many WordPress sites.
• MERN: MongoDB, Express, React and Node.js. JavaScript from the interface all the way to the server.
• TALL: Tailwind CSS, Alpine.js, Laravel and Livewire. A modern PHP stack where much of the interface is rendered on the server.

And four terms that show up in almost every proposal:

• A language is what the code is written in, such as PHP, JavaScript, Python or C#.
• A framework is a ready-made skeleton built on a language, with solutions for what every system needs: login, forms, email. Laravel, Django and Next.js are frameworks.
• A full-stack developer works on both the frontend and the backend. That's what I do.
• Open source means the code is free to use and anyone can read it. Most modern languages and frameworks are open source.

How your tech stack drives cost

Between two mainstream stacks, the hourly rate is rarely the big difference. Rates tend to vary more with seniority and location than with the stack itself. What moves the price is how many hours the work takes and what the product costs to keep running afterwards. Four things matter most.

What comes built in

A mature framework like Laravel ships with login, permissions, email, queues and scheduled tasks, either built in or as official packages, and Rails and Django cover much of the same ground. In the booking system, that means paid hours go into calendar logic and cancellation rules instead of rebuilding login from scratch. A minimal setup assembled from loose packages can look cheaper at the start, but every package is one more thing to choose, wire up and keep updated.

How many moving parts there are

One application is cheaper to build and run than a separate frontend, a separate API and a mobile app. Three codebases mean three places to fix bugs, three release processes and more coordination. There are good reasons to split things up, but for most new products it's premature. I explain why in monolith vs microservices.

Running costs

The framework itself is usually free. What you pay for every month is hosting, backups, error tracking and the third-party services: a fee per card payment, a price per SMS, perhaps an email provider subscription. With enough users, those can outgrow the hosting bill. Always ask which services a stack depends on and how each one charges.

Updates

Every layer gets new versions, and old versions eventually stop receiving security fixes. Laravel ships a new major version every year and provides security fixes for two years per release. That's a predictable rhythm, but it means someone has to upgrade the system regularly. Put it off for years and the bill grows, which is a classic source of technical debt.

How your stack decides who can take over the code

Your developer might get sick, take a full-time job or turn down your next project. Then someone else has to pick it up, and the first thing a new developer asks is what the system is built with. The more people who know your stack, the faster you find a replacement and the sooner they're productive.

Adoption varies a lot. In Stack Overflow's 2025 Developer Survey, about 66% of respondents say they did extensive work in JavaScript over the past year, about 45% in React and about 19% in PHP, while Laravel sits at about 9%. It's a global survey, but it shows the gap between the true mainstream and smaller, still sizeable ecosystems. On the web, PHP is far from niche: according to W3Techs, around 70% of websites with a known server-side language run on PHP (2026).

The point isn't to pick whatever is most popular. It's to make sure a realistic number of developers can work in your stack. A mainstream stack also widens your search beyond your own country: if you're based in Scandinavia or elsewhere in Europe, you can hire a Laravel or React developer anywhere in the EU and still share most of your working hours. The risk starts when your stack is so rare that you only know one person who can touch it.

How to judge a proposed tech stack in five steps

As a client, you rarely need to choose the technology yourself. You do need to judge whether the recommendation you're given makes sense. Here's how I'd approach it from your side of the table:

1. Start with the problem, not the technology. Write down what the system has to do, who uses it and which other systems it must talk to. Requirements like real-time updates, large data volumes, offline use or a mobile app shape the choice far more than personal taste.
2. Ask who will maintain it three years from now. If the answer is "only me", ask how easy it would be to find someone else. A common stack with good documentation is your insurance policy.
3. Prefer mature over new. A framework that has been around for years, ships updates on a published schedule and has a large community is a safer bet than the latest thing. My own default for web apps is Laravel, and I've written about why Laravel is my go-to framework, downsides included.
4. Count the moving parts. How many codebases, servers and outside services does the solution involve? If the number is higher than the project needs, you're paying for complexity you won't use. A typical decision here is whether everything lives in one Laravel application or the interface gets built separately in Next.js. I compare the two in Laravel vs Next.js.
5. Check data, licenses and ownership. Where is the data stored, and is it inside the EU? That matters for GDPR and for your customers' security reviews. Are there recurring license fees? And are the code repository, hosting account and domain in your company's name?

If you're building a SaaS product, I give a more specific recommendation in my take on the best SaaS tech stack.

When the tech stack isn't your biggest problem

Your stack matters, but it isn't always the most important question. In these situations, your energy is better spent elsewhere:

• You need a standard marketing website. The platform effectively picks the stack for you, whether that's WordPress, Webflow or Shopify, and the real question is which platform fits.
• Off-the-shelf software already covers most of what you need. Buying is often cheaper than building, and the stack becomes the vendor's responsibility.
• You have an in-house development team. New systems should usually be built in the stack they already know. If your team works in .NET or Python, hire a developer with that background, not someone like me who works in Laravel and JavaScript.
• You don't yet know whether anyone will pay for the idea. Getting in front of real users quickly matters more. A proven framework helps, but no stack rescues a product nobody wants.

Next steps

If you've been handed a stack recommendation, or you're about to start a new project, bring these questions to your next conversation with a developer:

If a developer can't answer these clearly, that tells you something on its own. To see the kinds of products I build and what I build them with, take a look at my development services.

Frequently asked questions

Can you change your tech stack later?+

Yes, but it's rarely cheap. Switching backend language or framework usually means rewriting large parts of the system while the old one keeps running. A gradual migration is often the safer route: build new parts in the new stack and let them talk to the old system through an API. That's why it pays to choose carefully at the start rather than switch later.

Is PHP still a good choice for new projects?+

Yes. PHP earned a bad reputation in the 2000s, but the language has modernized a lot, and frameworks like Laravel and Symfony are used for new systems today. There's a large pool of developers and a mature ecosystem of packages and tools. For any system, the language matters far less than whether the code is well written and kept up to date.

Does your tech stack affect SEO?+

Yes, but mostly indirectly. Google can usually process pages built with JavaScript in the browser, but it's safer when the server sends complete pages, so content and links are there on the first load. Speed counts too, and it depends more on how a site is built and hosted than on the framework itself. Pages behind a login aren't visible to Google, so there it makes no difference.

How long does a tech stack last?+

A widely used framework can carry a system for many years if it's updated regularly. What wears out is rarely the technology itself. It's versions that never get upgraded and code written without structure. A system that has sat untouched for several years can cost more to update than to rebuild, so plan maintenance and an upgrade budget from the start.