Full stack developer roadmap

Frameworks change every few years; the layer beneath them barely moves. Developers who understand HTTP, the browser and the language adapt to a new framework in weeks. Developers who only know a framework start over each time.

This is the single most consequential decision in how you spend your learning time. Spend it disproportionately on the parts that will still be true in ten years.

It is also the difference between debugging and guessing. When a request behaves unexpectedly, understanding caching headers, cookies and status codes gives you a place to look; framework knowledge alone gives you a search query.

• HTTP — methods, status codes, headers, caching, cookies
• How a browser turns a request into pixels, and what blocks it
• JavaScript itself — closures, promises, the event loop, modules
• The DOM, independent of any framework
• Accessibility basics, which are increasingly a legal requirement

Choose one frontend framework and one backend language and go deep. Jumping between stacks is the most common way to spend two years and remain unemployable, because nothing reaches the depth an interview probes.

Deep means understanding the model rather than memorising the API: how rendering and state updates actually work, why an effect runs when it does, what happens on the server versus the client. That understanding is what lets you debug rather than guess.

The anxiety about choosing the wrong one is misplaced. Hiring managers care that you can reason about a system, and someone fluent in one modern stack is trusted to pick up another — which is exactly what happens on the job anyway.

Most self-taught developers can use an ORM and cannot explain what it generates. That gap appears immediately in interviews and in production, where the slow endpoint is nearly always a query problem.

Learn SQL directly, not only through an abstraction. Schema design, normalisation and when to break it, indexes and why the wrong one is useless, transactions, and how to find the query making a page slow.

The specific thing worth being able to spot is a query running once per row of a previous result. It is the most common performance defect in application code, it is invisible until you look at what the ORM emitted, and naming it in an interview signals real experience.

• SQL written by hand, not only generated
• Schema design and sensible relationships
• Indexing — what it does and when it does nothing
• Transactions and isolation, at a working level
• Reading a query plan to find what is slow

Auth appears in essentially every application and is implemented badly in most portfolio projects. Building it correctly once — sessions or tokens, password hashing, refresh handling, authorisation distinct from authentication — teaches security thinking that transfers everywhere.

Know the difference between authentication and authorisation and be able to state it crisply. Confusing the two is a common interview stumble and a common source of real vulnerabilities.

The failure worth understanding deeply is the missing ownership check: an endpoint that verifies who you are and never verifies that the record belongs to you. It is the most common serious vulnerability in applications built by capable developers, precisely because the authentication part looks correct.

A project that only runs on your machine is half a project. Deploying forces you to confront environment configuration, secrets, build steps, database migrations and the first time something works locally and fails in production.

You do not need sophisticated infrastructure. A managed platform is fine. What matters is that the application is reachable, that you configured it, and that you can explain what happens between a commit and the running site.

The lessons arrive quickly and stick. Secrets that should not be in the repository, a migration that ran in the wrong order, a build that succeeded locally because of a file you never committed — each of these is a half hour of frustration and a permanent piece of understanding.

Two or three substantial projects beat a dozen tutorials. Substantial means real authentication, a database with meaningful relationships, some tests, deployment and a README that explains decisions rather than listing features.

Build something with an actual user, even one — a tool you or someone you know uses. Projects with a real user have edge cases, feedback and decisions to defend, which is precisely what interviewers dig into and what clone projects cannot provide.

Write the README for a reviewer who has ten minutes. What it does, why you chose the stack, one thing that was harder than expected and how you resolved it. That last paragraph is read more carefully than any of the code.

• Real auth, not a hardcoded login
• A database with relationships and constraints
• Tests covering the parts that matter
• Deployed and reachable
• A README explaining why, not just what

Boilerplate is faster to produce, which reduces the value of memorising syntax and raises the value of judgement: knowing what to build, recognising when generated code is wrong, and owning what ships.

The practical consequence for a learner is that reading code critically matters more than it used to. Accepting generated code you cannot explain builds an impressive-looking repository and no actual capability — and interviews find that out quickly.

The safest way to use these tools while learning is to write the first version yourself, then ask for a critique. That preserves the struggle that builds understanding while still getting the benefit of a second opinion on structure.