Find Your Stage on the Way to JavaScript Architect

A 20-box self-check across six stages, and a free 7-page roadmap with the plan for each one.

Nov 07, 2026

Most architect roadmaps are a chart with a hundred boxes and no order. Nothing on the chart tells you when a topic is done, so you skim all of them and practice none.

My own first version had the same problem. It was an 8-slide social carousel with six lists of five topics each, and nothing in it told you what to do with them. I rebuilt my JavaScript Architect Roadmap 2026 to fix that. It's now a 7-page PDF with six stages in the order they build on each other. Each stage has a check that tells you when to move on, and one project to do in the codebase you already have.

This issue gives you the part to start with, the self-check from page 2. It takes about five minutes and tells you which stage to work on next.

Share this post & I’ll send you some rewards for the referrals.

The six stages

Master the language. You can predict what any JavaScript does before you run it.
Write code that lasts. A stranger can change your code safely.
Design the application. A change to one feature touches one module, and the business rules don't know about Express, React or Postgres.
Tame the database. You design schemas, read query plans and pick isolation levels on purpose.
Survive distributed systems. Your design stays correct when a call times out or a message arrives twice.
Think like an architect. You compare real options, write the decision down and get a team to build it the same way.

Stages 1 and 2 are about writing code other people can trust. Stages 3 and 4 shape the application and the data under it. In stages 5 and 6 you make calls that span services and teams.

The self-check

Tick a box only if you could do it today without looking anything up, and explain it to a teammate. Your starting stage is the first one with an empty box.

Be strict with yourself. The gaps from a skipped stage tend to show up later as production incidents.

1. Master the language

Predict the output order of code that mixes setTimeout, await and Promise.then.
Type a function whose return type depends on its argument, with no any and no as.
Find an async bug with a debugger or a failing test, without adding console.log lines.

2. Write code that lasts

Refactor a 200-line function in small, tested steps.
Say when your code throws and when it returns an error, and point to the rule.
Get a pull request approved by someone who has never seen the module, without a call.
Reject an AI-written pull request for a design reason, and name the rule it broke.

3. Design the application

Draw your app's modules and the direction of every dependency between them.
Test a feature's business rules without a database, a server or a browser.
Point to the one place where each kind of external input gets validated.

4. Tame the database

Read an EXPLAIN ANALYZE plan and say why Postgres picked it.
Name the isolation level your transactions run at, and one anomaly it allows.
Rename a column in production with zero downtime.

5. Survive distributed systems

Explain what happens when a payment call times out and the client retries.
Publish an event after a database write without writing to two systems.
Follow one request through logs and traces across every service it touches.

6. Think like an architect

Write a one-page decision record with two real options and what each costs.
Explain a technical trade-off to a product manager in terms of time, money and risk.
Name the two or three qualities your system optimizes for, and what it gives up.
List the trust boundaries in one feature and the attack you'd try at each.

What your result means

Empty boxes in stage 1 or 2? These stages move fastest, and everything later rests on them. Close those gaps first, even if your title already says senior.

Stuck at stage 4? That's the most common place to stall. Application code can hide a weak data model for years, until traffic grows.

Every box ticked? Go to page 6 of the roadmap. The habits there are what people notice when they decide who gets to make the big calls.

Finish one stage before you open the next

My estimate is two to four months per stage, with a full-time job and five focused hours a week. You'll move faster on the stages you already use at work.

The most common way to waste a year is to collect stages. Reading about sagas while your own service has no timeouts feels like progress, and it changes nothing in production. Pick your stage, do its practice project at work, and take the self-check again when you're done.

What's in the full roadmap

The self-check is page 2. The rest of the PDF is the plan for each stage:

Pages 3 to 5. Each stage gets a paragraph on why it matters, a diagram, six skills, a "move on when you can" checklist, a practice project for your own codebase, and two sources worth your time.
Page 6. Four habits that apply at every stage, with a sample decision record, the shape I use to write a trade-off, how to read a large codebase fast, and how to explain a design to people who don't write code.
Page 7. A 90-day plan for your current stage, and one book for each stage.

Here's the practice project for stage 4, so you can see the format:

Turn on pg_stat_statements, or open your provider's query insights. Take the three queries with the most total time and read their plans. Fix one with an index or a rewrite, and record the numbers before and after.

The roadmap is free. Enter your email on my site and the PDF arrives in your inbox a minute later.

Get the free JavaScript Architect Roadmap

Free JavaScript Architect Roadmap

Signing up also adds you to my email list on petarivanov.tech. You'll get a welcome email from there, and one click unsubscribes you from that list while you keep the PDF.