What is a tech stack?

What is a tech stack?

A tech stack is the set of technologies a product is built from, with one main choice per layer. The layers are the ones already on the table: a frontend the customer touches, a backend that does the thinking, a database that keeps the records, and a cloud that runs it all. A stack names the specific pick at each layer.

The word earns its name literally. The layers sit on top of each other. The frontend rests on the backend, the backend rests on the database, and everything rests on the machines underneath. Stack the picks up and you have described the whole product in four or five words, which is exactly what a hiring manager is doing when they say "our stack is React, Node, Postgres on AWS."

The shelves sorted every technology name by what kind of thing it is. A stack is the next move: one item taken down from each shelf. That is why a stack sentence is readable at all. It is a short list where every word answers a different question.

How do you read a stack sentence?

Take the sentence above apart word by word. "React" answers the frontend question: this is the framework the visible half is built in. "Node" answers the backend question: the thinking half runs on JavaScript, server-side. "Postgres" answers the database question. "AWS" answers where it all runs. Four words, four layers, no overlap.

Read this way, a stack sentence stops being a wall of jargon and becomes a form with four blanks. Any company's version fills the same blanks with different names. "Vue, Django, Postgres, on Google Cloud" is the same sentence with three picks swapped. Once the blanks are familiar, an unfamiliar name in one of them is a small lookup rather than a mystery, because the position already tells you what kind of thing it must be.

The same reading works in reverse on a resume. A skills list that includes one frontend framework, one backend language, one database, and one cloud provider is a person describing a complete stack they have worked across. A list that names four frontend frameworks and nothing else describes a different and equally legible shape: one layer, covered deeply, across several tools.

Why does every company have a different stack?

Stacks differ because they are chosen under different constraints, and most of the choices are reasonable. The product's needs come first. A tool that crunches large datasets pulls toward Python and its libraries. A product where the interface is the product pulls effort and tooling toward the frontend layer.

The team's existing skills come second. A founding engineer who has shipped twice in Ruby on Rails will pick it a third time, because speed matters more at the start than fashion. Hiring comes third, and it is the constraint recruiters see most directly: a company in a smaller city may pick a common stack over a niche one because the local pool decides how fast the team can grow.

Age leaves a mark too. A stack records when a company was founded, roughly the way a house records its decade. A ten-year-old product often carries an older frontend framework in its core, with newer picks at the edges, and that is normal. Whole products get rebuilt rarely, because software is never done and a rebuild competes with everything else on the roadmap.

So two companies solving near-identical problems can run on different stacks and both be right. This is why matching resume names against req names word for word undersells candidates. What transfers covers how far a skill carries between names on the same shelf.

What does "full stack" mean?

Full stack means a developer works across both halves of the application: the frontend the user sees and the backend behind the API. A full-stack developer can take a feature from the button on the screen down to the database row and back, without handing it off at the boundary.

The phrase describes range, and range is genuinely valuable. On a small team, one full-stack developer ships a complete feature alone. That is why early-stage companies write "full stack" on the req so often: they are buying whole features per person, because they have few people.

What the phrase does not carry is depth. "Full stack" says nothing about how deep the person goes at any single layer, and the same two words appear on the resume of a second-year developer and a fifteen-year veteran. The words set the width of the territory. The depth has to be read from the work itself, and that reading has a name covered below.

Which half does a full-stack developer usually lean toward?

Nearly every full-stack developer leans toward one half, and the lean is a fact about their history rather than a flaw. People enter the field through one door. Someone who started in frontend and grew backward carries a designer's instincts about interfaces. Someone who started in backend and grew forward carries a systems person's instincts about data and reliability. Years later both write "full stack," and both are telling the truth about their range while the lean stays put.

The lean tends to show before anyone says it out loud. The half a developer names first is usually the home half. The half where their skills list gets specific, naming particular tools rather than a category, is usually the home half. Public work leans the same way: a repository list heavy with interface projects belongs to a frontend-leaning developer, whatever the resume headline says.

What is a specialist, and what is a generalist?

A specialist has depth in one layer: a frontend specialist, a database specialist, an infrastructure specialist. A generalist covers several layers at working depth. Both shapes ship products, and teams need them in different proportions at different sizes. A five-person startup runs on generalists, because every person must cover ground. A five-hundred-person company grows specialists, because at scale each layer holds enough hard problems to fill a career.

Depth itself has a name worth keeping: domain depth. It means sustained, hard-won expertise in one problem area, the kind that shows up as years of work circling the same territory. Domain depth can live inside any shape. A generalist with domain depth in payments is a generalist whose depth happens to be a business domain rather than a technical layer, and for a fintech req that combination can outweigh any stack match.

One more shape completes the set. A polyglot developer works in several programming languages. The name comes from the word for a person who speaks many languages, and it signals the same thing: adaptability, and proof that they can pick up a new one. Range across languages, like range across layers, says where someone has been. Depth still has to be read from the work, and the next lesson covers how far each kind of range actually carries.