Build Your Own X: Systems

This phase is where Build Your Own X shines: most of the legendary tutorials in the BYO-X catalog live here — compilers, interpreters, OSes, shells, Git, Docker, TCP stacks. The systems phase already pushes you toward bare-metal, so the elective projects deepen the same muscles.

Each project here is a self-contained tutorial: research links, the curated BYO-X external tutorial list preserved verbatim, recommended primary path, implementation milestones with code sketches, evidence requirements, common pitfalls, and module integration notes.

The quality bar is higher than "finished the tutorial." A completed systems project must include a written contract for the machine, language, protocol, file format, or syscall boundary it implements; a test suite that covers failure cases; at least one trace from the running system; and a short design note explaining where the implementation is deliberately incomplete.

Use source guides responsibly

The BYO-X repository is a curated catalog of external tutorials. Read them when needed, then write your own code, your own explanation, and your own tests. Do not paste external tutorials into your portfolio.

---

Projects in this phase

Project	Primary module fit	Difficulty	Languages typically used
Memory Allocator	Sem 4 M2 — memory & pointers	Medium	C
Shell	Sem 4 M4 — systems-level programming	Medium	C, Rust, Go
Interpreter (Tree-Walking)	Sem 4 M5 — abstraction & interpretation	Medium	Any
Compiler	Sem 4 M5 — abstraction & interpretation	Hard	Java, C, Go, OCaml
Text Editor (kilo-style)	Sem 4 M1 — C fundamentals	Easy–Medium	C, Rust
Git	Sem 4 M1 / Sem 5 storage	Medium	Python, Ruby, Haskell
Emulator (CHIP-8 / GB)	Sem 4 M3 — computer organization	Medium–Hard	C, C++, Rust
Operating System	Sem 5 M1–M2 — OS, memory	Hard	Rust, C, Assembly
Network Stack (TCP)	Sem 5 M5 — networking	Hard	C, Rust
Docker / Container Runtime	Sem 5 M3–M4 — concurrency, FS	Medium	Go, Python, C
BitTorrent Client	Sem 5 M5 — networking	Medium	Go, Python, Node.js
Regex Engine	Sem 4 M5 — abstraction & interpretation	Medium	Python, Go, C

Additional local book-backed projects:

Project	Primary module fit	Difficulty	Languages typically used
Toy Computer	Sem 4 M3 - computer organization	Medium	Python, C, Rust
Source Code to Machine Code	Sem 4 M3/M5 - compiler/codegen	Hard	Python, C, Assembly
MLIR Compiler Pipeline	Sem 4 M5 - advanced compiler infrastructure	Hard	C++, Python

Cross-phase projects (covered in other phases):

• Foundations: Neural Network, LLM, 3D Renderer
• Architecture: Database (KV), Web Server
• Production: Front-end Framework, Game Engine 2D

---

Systems module → project map

Semester 04: Systems Programming

Module	Recommended BYO projects	Why it fits
Module 1 — C programming fundamentals	Text Editor (kilo), Shell	Both are classic "write a small but complete program in C" exercises with realistic edge cases
Module 2 — Memory, pointers, machine representation	Memory Allocator	Forces direct engagement with ownership, fragmentation, alignment
Module 3 — Computer organization & architecture	Toy Computer, Emulator, Source Code to Machine Code	Toy Computer defines a machine, Emulator implements a real one, Source-to-Machine-Code proves how programs target one
Module 4 — Systems-level programming	Shell, Docker (light version)	fork/exec/pipe/dup2 and namespaces
Module 5 — Abstraction & interpretation	Interpreter, Compiler, Source Code to Machine Code, Regex Engine, MLIR Compiler Pipeline	Start with syntax and evaluation, then move through bytecode, native code, automata, and modern multi-level IR

Semester 05: OS and Networking

Module	Recommended BYO projects	Why it fits
Module 1 — Processes & scheduling	Operating System (Phil Opp's blog_os covers scheduling around chapter 7+)	Real schedulers, not simulators
Module 2 — Memory management & virtual memory	Operating System (paging chapters)	Page tables, frame allocator, heap
Module 3 — Concurrency & synchronization	Docker / Container, BitTorrent Client	Both require correct concurrent I/O
Module 4 — File systems & I/O	Git, Docker	Git is a content-addressable filesystem on top of a normal filesystem
Module 5 — Network protocols & sockets	Network Stack (TCP), BitTorrent Client	TCP from scratch, then a real peer-to-peer protocol

---

Local source additions

The local Build Your Own source set adds three systems projects beyond the original BYO-X catalog shape. These source IDs refer to local material under the workspace/library source set, not to committed generated reference pages:

• Toy Computer, source ID build-your-own/toy-computer, belongs before or beside the emulator project.
• Source Code to Machine Code, source IDs build-your-own/source-to-machine-code-james-smith and build-your-own/c-compiler-nora-sandler, is the native-code path after the compiler project.
• MLIR Compiler Pipeline, source ID build-your-own/mlir-oren-davis, is the advanced compiler-infrastructure path after the basic compiler.

Use them when the learner wants deeper computer-architecture or compiler evidence than the standard interpreter/compiler pages provide.

---

Project quality rubric

Dimension	Minimum acceptable evidence	Strong evidence
Specification	one-page language, ISA, protocol, or ABI contract	versioned spec with examples and rejected cases
Tests	happy path plus malformed input	golden tests, randomized/model tests, and regression fixtures
Observability	one trace, dump, or log from the running system	trace mode that explains every state transition
Correctness oracle	manual expected output	interpreter/reference model/differential test where possible
Performance	one measurement after completion	repeatable benchmark with p50/p95 and a written caveat
Portfolio	README and demo command	design note, limitations, test transcript, and reproducible build

This is the main improvement over dumping book material into the plan: each book-backed project now has to produce inspectable engineering evidence.

---

Build rules (stricter for systems)

1. Tiny working systems beat large unfinished rewrites. A 200-line interpreter you can extend beats a 2,000-line "almost-compiler" you cannot.
2. Source + tests + traces + notes live in the same repo.
3. Every module build must include one failure case. A working demo is half the evidence.
4. Every system call, memory boundary, or protocol assumption needs proof. strace, sanitizer logs, packet captures, or a written invariant.
5. Reproducibility matters. A reviewer must be able to build and run your project on a clean machine from your README.

---

Source

• Catalog: codecrafters-io/build-your-own-x
• Browsable mirror: build-your-own-x.vercel.app
• Books, paid tutorials, and 3rd-party guides for every project: see the Build Your Own X — Books & Paid Resources guide in the portal.