A Complete Computer Science Roadmap for Builders
A practical computer science roadmap for builders: what to learn first, what to study next, what to skip, and how to turn the map into real projects.
You do not need to memorize the whole map.
You need a route.
A useful computer science roadmap does three things:
- It tells you what to learn first.
- It tells you what can wait.
- It gives you projects that force the concepts to become real.
This roadmap is for builders. It is not the academic order. It is the order that pays off fastest when you are trying to ship real software.
How to use this series
Use this page as the hub.
Read Part 0 to understand the four neighborhoods: data structures, algorithms, system design, and development process.
Use Part 1 when you need arrays, hash maps, stacks, queues, trees, and graphs.
Use Part 2 when your app gets slow or you need Big O, binary search, and recursion.
Use Part 3 when you need HTTP, APIs, databases, caches, queues, load balancers, or tradeoffs.
Use Part 4 when you need Git, reviews, tests, CI/CD, and technical debt management.
Use Part 6 after you ship something real and need monitoring, tracing, CI gates, and automated guardrails.
For deployment-specific work, pair this roadmap with the Deployment Guide for Vibe Coders.
The roadmap in one picture
Think in stages, not topics.
Know the neighborhoods. Do not study randomly.
Data structures, Big O, and the shape of slow code.
HTTP, APIs, databases, auth, and permissions.
Git, reviews, tests, CI/CD, rollback thinking.
Deployment, logs, metrics, queues, retries, cost control.
Go deeper into AI apps, backend, frontend, infra, security, or data.
The dependencies are simple:
| If you want to understand... | Learn this first | Then learn |
|---|---|---|
| Why code gets slow | Hash maps and Big O | Indexes, caching, profiling |
| How web apps work | HTTP request/response | APIs, auth, databases, deployment |
| How teams ship safely | Git branches and pull requests | Tests, CI/CD, reviews, rollback |
| How production systems fail | Logs and metrics | Tracing, alerts, CI gates, guardrails |
| How AI apps scale | Background jobs and cost tracking | RAG, embeddings, queues, rate limits |
Stage 0: Orientation
Do this before you go deep.
You should be able to explain the four neighborhoods in plain language:
- Data structures: how data is stored so it can be found, changed, grouped, and connected.
- Algorithms: the steps your program follows and how those steps behave as data grows.
- System design: the shape of the app: clients, servers, APIs, databases, caches, queues, external services.
- Development process: the habits that keep software changeable: Git, reviews, tests, CI/CD, debt management.
Checkpoint:
- I can look at a bug or slow feature and guess which neighborhood it belongs to.
- I can explain why I am learning a concept before I spend time on it.
- I have one real project where I can apply what I learn.
Stage 1: Code reasoning
Start here because it changes how you read code immediately.
Learn:
- Arrays and lists.
- Hash maps and sets.
- Stacks and queues.
- Trees and graphs.
- Big O.
- Binary search.
- Recursion.
Do not try to memorize every data structure. Learn the practical question:
How should this data be stored so the app can find it, change it, and connect it without wasting work?
Builder exercises:
| Exercise | What it teaches |
|---|---|
Replace repeated array.find() calls with a Map | Direct lookup and Big O |
| Add pagination to a list page | Linear growth and API limits |
| Build nested comments | Trees and recursion |
| Build a simple job queue | FIFO queues and background work |
| Detect duplicate records | Sets and uniqueness |
You are ready to move on when:
- You can spot a suspicious nested loop.
- You can explain why direct lookup is faster than repeated scanning.
- You can choose between array, hash map, queue, tree, and graph for common app problems.
- You can estimate whether a piece of code is roughly O(1), O(log n), O(n), or O(n²).
Stage 2: Web app foundations
Most builders need this before advanced algorithms.
Learn:
- HTTP methods, status codes, headers, request bodies, response bodies.
- REST basics and when GraphQL or RPC may help.
- JSON and basic serialization.
- SQL vs NoSQL.
- Tables, documents, indexes, migrations, and query shape.
- Authentication and authorization.
- Sessions, JWTs, OAuth, roles, permissions.
- Secrets and environment variables.
The practical question is:
Can I draw what happens from browser click to database write and back?
Builder exercises:
| Exercise | What it teaches |
|---|---|
| Draw one browser → API → server → database flow | Request lifecycle |
| Add login and logout | Sessions, cookies, auth state |
| Add role-based access to an admin page | Authorization and permissions |
| Add a database migration | Schema change discipline |
| Add an index and compare query speed | Database performance |
You are ready to move on when:
- You can draw a request flow without guessing.
- You know where secrets belong and where they do not belong.
- You can explain the difference between authentication and authorization.
- You can identify the main tables or documents your app owns.
- You can name the risky endpoints in your app.
Stage 3: Safe engineering workflow
This is the stage that lets you work with other people, or with future-you.
Learn:
- Git branches, commits, pull requests, merges, and reverts.
- Code review as a risk-control system.
- Unit, integration, and end-to-end tests.
- Mocking and test data.
- CI/CD basics.
- Rollback thinking.
- Technical debt tracking.
- Basic code organization: modules, layers, boundaries, MVC-style separation.
The practical question is:
Can I change this app without making the next change harder or riskier?
Builder exercises:
| Exercise | What it teaches |
|---|---|
| Use branch → PR → review → merge, even solo | Change control |
| Add tests around login, payment, deletion, or permissions | Risk-based testing |
| Add a CI check that runs tests before merge | Automated safety |
| Write a short PR description with risks and rollback plan | Review discipline |
| Refactor one messy file into smaller modules | Code organization |
You are ready to move on when:
- Your project can be changed through small branches.
- Risky flows have tests.
- You know how to revert or roll back a bad change.
- You keep a debt list instead of relying on memory.
- You can ask AI for a PR review instead of only asking it to generate code.
Stage 4: Production readiness
A demo only has to work once.
A production app has to keep working when users, data, cost, and failures grow.
Learn:
- Deployment basics: build, environment variables, domains, logs, rollbacks.
- Containers, serverless, and managed services at a practical level.
- Caching, background jobs, queues, retries, idempotency.
- Logging, metrics, tracing, alerts.
- Performance profiling and measurement.
- Slow query logs and query plans.
- Rate limits and API quotas.
- Security basics: OWASP Top 10, input validation, XSS, CSRF, SQL injection, dependency risk.
- AI-specific production risks: token cost, model latency, rate limits, retries, prompt injection, data leakage.
The practical question is:
What will break first if this app gets 10x more users, 10x more data, or 10x more AI calls?
Builder exercises:
| Exercise | What it teaches |
|---|---|
| Add structured logging around one risky request | Debuggability |
| Track p95 latency for one endpoint | Performance measurement |
| Move a slow AI/file/email task into a background job | Queues and timeouts |
| Add retry with idempotency to a webhook processor | Failure handling |
| Add token/cost tracking around AI calls | AI production economics |
| Add alerts for error rate, latency, job failure, and cost spikes | Operational guardrails |
You are ready to move on when:
- You can tell whether the app is healthy without clicking around manually.
- You know which endpoint, job, or AI call is most likely to fail.
- You have basic logs, metrics, and alerts.
- You can deploy and roll back deliberately.
- You have automated checks for the most predictable production failures.
Stage 5: Deeper computer science
This is where the map gets wide.
Do not study all of it at once. Pick the topic when your project creates the need.
Processes, threads, memory, file systems, I/O, CPU scheduling. Study this when debugging performance, crashes, memory, or local runtime behavior.
TCP/IP, DNS, TLS, WebSockets, webhooks, proxies. Study this when requests fail, realtime features matter, or infrastructure gets confusing.
Event loops, promises, threads, locks, race conditions, parallelism. Study this when tasks overlap or timing bugs appear.
Transactions, ACID, indexes, query planners, replication, sharding. Study this when data integrity or query performance becomes a real constraint.
Threat modeling, OWASP, auth boundaries, input validation, secrets, dependency risk. Study this before handling sensitive user data.
Consistency, availability, consensus, retries, partitions, queues. Study this when one service or one database is no longer enough.
The 30-day starter plan
Use the first month to build working instincts.
| Days | Focus | Exercise | Deliverable |
|---|---|---|---|
| 1–3 | Hash maps and arrays | Rewrite one feature to use direct lookup instead of repeated scanning | Before/after note explaining the lookup |
| 4–6 | Big O | Mark the expensive parts of your app with rough complexity notes | A short list of O(1), O(n), and possible O(n²) spots |
| 7–10 | HTTP and APIs | Draw one request flow from browser to database and back | A request-flow diagram |
| 11–14 | Database basics | Identify tables/documents, owners, permissions, and indexes | A small data model map |
| 15–18 | Git flow | Use branch → PR → review → merge, even if reviewing yourself | One clean merged PR |
| 19–21 | Tests | Add tests around login, payment, permissions, or deletion | A risk-based test |
| 22–25 | System design | Decide whether cache, queue, or background job is needed | A tradeoff note, not necessarily new infrastructure |
| 26–30 | Review and debt | Write a technical debt list and repay one item | A debt list with one closed item |
The 90-day builder roadmap
Use the next two months to make the app safer, clearer, and more production-ready.
| Days | Focus | What to learn | Deliverable |
|---|---|---|---|
| 31–45 | Auth and security | Sessions, JWT, OAuth, roles, OWASP basics, validation, secrets | Auth flow diagram and permission checklist |
| 46–60 | Async and background work | Event loop, promises, queues, retries, idempotency, webhooks | One background job or webhook processor |
| 61–75 | Database depth | Migrations, transactions, indexes, query plans, connection pooling | One measured query improvement |
| 76–90 | Production guardrails | Logs, metrics, tracing, alerts, CI gates, cost tracking | A minimal production dashboard and pre-deploy checklist |
By day 90, you should have shipped one real project with:
- Auth and permissions.
- Persistent data.
- At least one tested risky flow.
- A deliberate deployment path.
- Basic logging or monitoring.
- A debt list.
- One production guardrail.
The 6-month roadmap
This is the practical depth path.
| Month | Goal | Focus |
|---|---|---|
| 1 | Build foundations | Data structures, Big O, HTTP, database basics, Git, tests |
| 2 | Ship a real app | Auth, permissions, migrations, deployment, rollback |
| 3 | Make it observable | Logs, metrics, tracing, alerts, slow query analysis, AI cost tracking |
| 4 | Improve architecture | Modules, layers, API boundaries, background jobs, caching, queues |
| 5 | Measure and scale | Profiling, load testing, pagination, rate limits, indexes, performance budgets |
| 6 | Specialize | AI systems, backend, frontend architecture, infra/devops, security, or data systems |
The point is not to finish computer science in six months. The point is to build a mental index: when something breaks, you know where to look.
Project ladder
Projects make the roadmap stick.
| Level | Project | Concepts forced into practice |
|---|---|---|
| Beginner | Todo app with persistence | CRUD, database records, simple state |
| Beginner | URL shortener | Hash maps, lookup, routing, redirects |
| Beginner | Blog or notes app | Data modeling, markdown/content, auth optional |
| Intermediate | Authenticated dashboard | Sessions, permissions, API boundaries |
| Intermediate | Paginated admin table | Query limits, indexes, API response shape |
| Intermediate | Webhook processor | Queues, retries, idempotency, logs |
| Advanced | Chat or realtime collaboration app | WebSockets, concurrency, presence, ordering |
| Advanced | RAG knowledge base | Embeddings, vector search, chunking, ranking, cost |
| Advanced | Monitored AI app | Background jobs, tracing, token budgets, alerts, rollback |
Pick one project. Keep improving the same project across stages. Starting a new tutorial every week usually teaches less than pushing one app through more realistic constraints.
When to go deeper
Use pain as the trigger.
| If the pain is... | Study this |
|---|---|
| The app gets slow as data grows | Big O, database indexes, pagination, profiling |
| List screens freeze or responses get huge | API design, pagination, caching, frontend rendering |
| Login and permissions feel risky | Auth, authorization, sessions, security basics |
| Users wait on long AI or file work | Queues, background jobs, retries, idempotency |
| Bugs come back after every change | Tests, code review, modular design, CI |
| Production failures are hard to diagnose | Logs, metrics, tracing, alerts |
| AI bills grow unexpectedly | Token accounting, caching, rate limits, model selection |
| One server or one database is not enough | Scaling, replication, queues, distributed systems |
What to skip for now
A roadmap is useful because it protects your attention.
Skip these until you have the matching problem:
- Kubernetes before you have deployment or scaling pain.
- Microservices before you have team or domain complexity.
- Advanced graph algorithms before you have graph problems.
- Distributed consensus before you run distributed systems.
- Compiler internals before language/runtime behavior matters.
- Hand-rolled cryptography or authentication instead of trusted libraries.
- Performance optimization before measurement.
- Endless tutorials before one project has users or real usage.
Learning tactics with AI
AI can accelerate the roadmap if you ask it to explain the concept, not just produce code.
"Explain the CS concept behind this code with a simple analogy, one production risk, and one small exercise."
"Estimate Big O and identify the first bottleneck at 10x, 100x, and 1000x data. Suggest the smallest measurable improvement."
"Draw the request flow and name the client, API, server, DB, cache, queue, worker, and external services."
"Review this as a pull request. Prioritize security, data loss, permissions, observability, and rollback risk."
Use this loop:
- Build until something hurts.
- Name the pain.
- Place it on the map.
- Learn the smallest concept that explains it.
- Apply it immediately.
- Measure or review the result.
- Write the lesson in your own words.
That loop is slower than binge-watching tutorials, but it compounds.
Frequently asked questions
How long does it take to learn computer science for building?
You do not need to learn everything. Most builders can cover the practical foundations in 30 to 90 days of focused, project-driven study.
What should I learn first?
Start with data structures and algorithms that match the pain you already feel in your project, then move to system design and process as your app gets users.
Do I need to learn advanced algorithms?
Not until you have a real problem that needs them. Most production apps are limited by data structure choice, API design, and database queries long before advanced algorithms matter.
How do I avoid tutorial overload?
Stop watching tutorials that are not connected to a project you are building. Learn the smallest concept that removes your current blocker, apply it, then return for the next concept.
Should I learn a framework or computer science first?
Learn them together. Build with a framework, and when you hit a performance, structure, or process problem, learn the computer science concept that explains it.
Minimum viable computer science checklist
If you build with AI coding tools, keep this checklist nearby.
- I can explain arrays, hash maps, queues, trees, and graphs with examples.
- I can spot a suspicious nested loop.
- I can explain why direct lookup is faster than repeated scanning.
- I can draw a browser → API → server → database request.
- I know the difference between authentication and authorization.
- I know where secrets belong.
- I know when a background job or queue is needed.
- I use Git branches and commits intentionally.
- I know what kind of test belongs around risky logic.
- I can deploy and roll back deliberately.
- I can find basic logs, metrics, and errors after deployment.
- I track technical debt instead of relying on memory.
- I ask AI to explain the concept, risk, and tradeoff, not just produce code.
The takeaway
You do not need to finish computer science. You need a loop.
Build until something hurts. Name the pain. Place it on the map. Learn the smallest useful concept. Apply it. Measure it. Write it down. Repeat.
About the Author
Jaehee Song
Enterprise data platform architect with 20+ years of experience building data systems for Fortune 500 companies. AI development educator who has taught vibe coding and AI development to hundreds of students. Founder of Seattle Partners, helping Korean technology startups navigate the US market.