Scale
Millions of users or petabytes of data. Every design choice has to hold at 100× today's load.
Example: a feed that serves 100,000 requests per second
Companion guide · Software engineering beyond web & apps
Web and app development is one layer of a much deeper stack.
Websites and mobile apps sit at the top of a stack that runs down through backends, cloud infrastructure, data systems, operating systems and hardware. This page maps that wider field, sizes the market, and shows where demand is strong and skills are scarce. The aim throughout is autonomy: running your own business so that your money, time and energy stay under your control, and you keep the full value of your work instead of a salary. A job is the first step on that path; the Leverage Roadmap shows the full route to a business that runs on systems.
Chapter 01
The map
Software is built in layers. Each layer relies on the one below it and hides that layer's complexity from the one above. Web and app developers mostly work in the top two layers. The further down you go, the closer you get to the hardware, and the more theory the work demands.
- Product & applications Websites, mobile apps, desktop apps, SaaS products, games You are here
- Backend services & APIs Business logic, REST / GraphQL / gRPC APIs, auth, payments Partly here
- Data & machine learning Pipelines, warehouses, streaming, model training and serving
- Platform & infrastructure Cloud, containers, Kubernetes, CI/CD, networking, observability
- Distributed systems & databases Storage engines, replication, consensus, message brokers
- Systems software Operating systems, compilers, runtimes, virtual machines, drivers
- Embedded & hardware interface Firmware, microcontrollers, real-time systems, FPGAs
Cutting across every layer are security, performance and reliability, and specialist domains such as finance, healthcare, aerospace and robotics that add their own rules.
Chapter 02
Disciplines
The main fields of software engineering. The depth column is a rough guide to how much computer science theory the work uses day to day, on a scale of 1 to 5. It is not a ranking of how valuable or difficult each person's job is.
| Discipline | What they build | Common languages | Depth |
|---|---|---|---|
| Web & app development | Websites, web apps, mobile apps | TypeScript, Swift, Kotlin, Dart | |
| Backend engineering | APIs, business logic, integrations | Go, Java, C#, Python, TypeScript | |
| Cloud, DevOps & platform | Infrastructure, deploy pipelines, internal developer platforms | Go, Python, Bash, HCL (Terraform) | |
| Site reliability (SRE) | Keeping large systems fast and available | Go, Python | |
| Data engineering | Pipelines, warehouses, streaming systems | SQL, Python, Scala, Java | |
| Machine learning & AI engineering | Model training, inference systems, AI products | Python, C++, CUDA | |
| Security engineering | Secure architecture, audits, detection, cryptography | Python, C, Go, Rust | |
| Distributed systems & databases | Storage engines, replicated databases, queues | C++, Rust, Go, Java | |
| Operating systems & kernels | Kernels, drivers, file systems, hypervisors | C, Rust, assembly | |
| Compilers & languages | Compilers, interpreters, JIT runtimes, tooling | C++, Rust, OCaml, Haskell | |
| Embedded & IoT | Firmware for devices with tight memory and power limits | C, C++, Rust | |
| Games & graphics | Game engines, rendering, physics | C++, C#, HLSL / GLSL | |
| High-performance computing | Scientific simulation, GPU and cluster computing | C++, Fortran, CUDA | |
| Low-latency finance | Trading systems measured in microseconds | C++, Rust, Java, OCaml | |
| Robotics & autonomy | Perception, planning and control software | C++, Python | |
| Safety-critical systems | Avionics, automotive, medical devices | C, Ada, SPARK, Rust |
Chapter 03
What makes it harder
The same idea, "store a user's data and show it back", is simple for a small business site and very hard for a bank with 50 million customers. These are the forces that add difficulty:
Concurrency
Many things happen at once. Race conditions and deadlocks appear only under load and are hard to reproduce.
Example: two people booking the last seat at the same moment
Distribution
Machines fail, networks drop or delay messages, and clocks disagree. You must design for partial failure.
Example: a payment that succeeds but its confirmation is lost
Latency
Hard time limits, from 100 ms for a web page down to microseconds in trading or milliseconds in control loops.
Example: a brake controller that must respond within 10 ms
Correctness
Some bugs cost money or lives. These fields use formal methods, exhaustive testing and certification.
Example: aviation software certified to DO-178C
Resource limits
Kilobytes of RAM, a coin-cell battery, no operating system. Every byte and CPU cycle counts.
Example: firmware on a sensor that runs for 5 years on one battery
Security & adversaries
Attackers actively look for your mistakes. One flaw can expose everything.
Example: a crypto wallet or a hospital records system
Regulation
Laws and standards dictate how you build, test, document and store data.
Example: PCI DSS for card data, HIPAA for US health data, ISO 26262 for cars, IEC 62304 for medical software
Chapter 04
CS foundations
These subjects underpin every discipline above. Web development lets you get far without them; deeper engineering work does not.
| Subject | Key ideas | Where it shows up |
|---|---|---|
| Data structures & algorithms | Big-O, hash tables, trees, heaps, graphs, sorting, dynamic programming | Everywhere, and in most technical interviews |
| Computer architecture | CPU pipelines, caches, memory hierarchy, SIMD, GPUs | Performance work, games, HPC, trading |
| Operating systems | Processes, threads, scheduling, virtual memory, file systems, system calls | Backend, infrastructure, embedded |
| Networking | TCP/IP, UDP, DNS, TLS, HTTP/2 and HTTP/3, load balancing | Backend, cloud, security |
| Databases | Indexes (B-trees, LSM trees), transactions, isolation levels, query planning | Backend, data engineering |
| Distributed systems | Replication, partitioning, consensus (Raft, Paxos), CAP and PACELC, clocks | Cloud, databases, large-scale backends |
| Compilers & languages | Parsing, type systems, intermediate representations, optimization, garbage collection | Tooling, runtimes, DSLs |
| Security & cryptography | Threat modeling, authentication, encryption, hashing, common vulnerabilities | Every system that faces the internet |
| Mathematics | Discrete math, probability and statistics, linear algebra, calculus | ML, graphics, algorithms, finance |
Chapter 05
System design
System design is deciding how the components of a large system fit together so it stays fast, available and correct as it grows. It is the core skill that separates senior engineers, and a standard part of senior interviews.
Building blocks
Load balancing
Spreads requests across many servers so none is overloaded and any can fail.
Caching
Keeps hot data in memory (Redis, CDN edges). The hard part is invalidating it when data changes.
Replication
Copies data to several machines for availability and read capacity; followers may lag behind the leader.
Sharding
Splits data across machines by key, so no single database holds everything.
Queues & streams
Kafka, RabbitMQ or SQS decouple producers from consumers and absorb traffic spikes.
Consistency models
Strong versus eventual consistency: whether every reader sees the latest write immediately.
Idempotency
Making retries safe, so charging a card twice by accident is impossible.
Rate limiting & backpressure
Protects services from overload by slowing or rejecting excess requests.
Latency numbers to know
Approximate costs of common operations on modern hardware. The right-hand column scales them up so that one nanosecond becomes one second, which makes the differences easier to feel.
| Operation | Time | If 1 ns were 1 s |
|---|---|---|
| Read from CPU L1 cache | ~1 ns | 1 second |
| Read from main memory (RAM) | ~100 ns | 1.7 minutes |
| Compress 1 KB of data | ~2 µs | 33 minutes |
| Random read from an NVMe SSD | ~16 µs | 4.4 hours |
| Network round trip in one data center | ~500 µs | 5.8 days |
| Hard disk seek | ~10 ms | 3.8 months |
| Round trip California → Netherlands → California | ~150 ms | 4.8 years |
Memory is fast, the network is slow, and distance is slowest of all. Most large-system design is about avoiding the bottom rows of this table.
Chapter 06
Architecture patterns
| Pattern | What it is | Good for | Costs |
|---|---|---|---|
| Monolith | One codebase, one deployable application | Small teams, early products, most agency work | Harder to scale teams; one bug can take down everything |
| Modular monolith | One deployable, with strict internal module boundaries | Growing products that may split later | Needs discipline to keep boundaries clean |
| Microservices | Many small services, each deployed independently | Large organizations with many teams | Network calls, distributed failures, heavy operations work |
| Event-driven | Services communicate by publishing and consuming events | Workflows, integrations, real-time data | Harder to trace and debug; eventual consistency |
| Serverless | Functions run on demand; the cloud manages servers | Spiky traffic, glue code, small teams | Cold starts, vendor lock-in, costs at high volume |
| CQRS & event sourcing | Separate write and read models; store every change as an event | Auditable domains such as finance and ledgers | Significant complexity; easy to misuse |
Most successful systems start as a monolith and split only when team size or scale forces it. Choosing microservices for a 3-person project is a common and expensive mistake.
Chapter 07
Engineering at scale
Large engineering organizations rely on practices that small web projects can mostly skip. Knowing them makes you credible with bigger clients.
Design documents & RFCs
A written proposal with context, options considered, trade-offs and a decision, reviewed before code is written.
Testing strategy
Many fast unit tests, fewer integration tests, a few end-to-end tests. Add load tests, fuzzing and property-based tests where the risk justifies them.
CI/CD
Every change is built, tested and deployed automatically, with feature flags, canary releases and quick rollback.
Observability
Logs, metrics and traces (for example with OpenTelemetry), so you can answer "why is this slow?" in production.
SLOs & error budgets
A target such as "99.9% of requests succeed in a month" allows about 43 minutes of failure. When the budget is spent, reliability work comes before new features.
Incident management
On-call rotations, clear incident roles, and blameless postmortems that fix the system rather than blame people.
Code review
Every change reviewed by another engineer for correctness, readability and design, backed by automated linters.
Secure development
Threat modeling, dependency scanning, secrets management and least-privilege access built into the process.
Chapter 08
Career levels
Most tech companies use a similar engineering ladder. The main thing that changes as you move up is scope: how large a problem you can own without supervision.
- Junior engineerCompletes well-defined tasks with guidanceTask
- Mid-level engineerDelivers features on their own, from design to productionFeature
- Senior engineerDesigns systems, leads projects, mentors others, handles ambiguitySystem / team
- Staff engineerSets technical direction across several teamsSeveral teams
- Principal engineerShapes architecture and strategy for the whole organizationOrganization
Alongside the engineering ladder there is a management track (engineering manager, director, VP of engineering, CTO) that focuses on people, hiring and delivery rather than hands-on technical work.
Chapter 09 · Part II
Why own work
The goal behind this whole handbook is autonomy: control over your money, your time and your energy. In a job, someone else decides all three. They set your salary, your hours and your projects, and they keep the difference between what your work is worth and what they pay you. In your own business you make those decisions, and the value you create comes to you.
Money
You set your prices, choose your clients and keep the margin an employer would otherwise keep.
Time
You decide your hours, your holidays, which projects you take on and when you stop.
Energy
You spend your effort on work and people you choose, and build something you own.
Job, freelancing and your own business compared
| Job | Freelancer | Agency / product business | |
|---|---|---|---|
| Who sets your income | Employer | You and the market | You and the market |
| Share of your value you keep | Salary only | Most of it | All of it, plus margin on others' work |
| Who decides your hours | Employer | You, within client deadlines | You |
| Who chooses the work | Employer | You | You |
| Income ceiling | Set by pay bands | Your rate × your hours | No fixed ceiling |
| Income stability | High | Varies month to month | Improves with retainers |
| What you build | Skills and a CV | Skills, reputation, client list | A sellable asset |
| Risk you carry | Layoffs | Gaps between clients | Payroll, overheads, bad debts |
The value gap
The median US software developer earned $135,980 in May 2025 (BLS). Agencies commonly bill a developer at $150–200 an hour. At 1,600 billable hours a year, that is $240,000–320,000 of billed work, roughly twice the salary. The gap pays for sales, management, idle time, overheads and the owner's profit. When you run the business, you do that work yourself and keep the gap.
The same pattern shows up in India. NASSCOM expects the Indian tech industry to earn $315 billion in FY2026 with a workforce of about 6 million. That is roughly $52,500 (about ₹45 lakh) of revenue per employee each year. Compare that with what you are paid.
Value capture calculator
Compare what you keep in a job with what you could keep running your own business, for the same skills. The example uses US figures; replace them with your own.
What autonomy costs
Owning the upside also means owning the downside. Plan for these from day one:
Uneven income
Fix: keep 3–6 months of expenses in reserve and build retainers.
You have to sell
Fix: set weekly outreach time, even when you are busy.
No paid leave or benefits
Fix: build them into your rate, as the rate calculator in the handbook does.
One client becomes your boss
Fix: keep any single client under about 30% of revenue.
The autonomy ladder
Each step gives you more control and ties your income less to your own hours. You don't need to skip steps; most people climb them in order.
Employee
Salary in exchange for your time. Stability, but the least control.
Employee with side projects
Test client work, a niche and your pricing before leaving the job.
Freelancer
You sell your own time directly and keep what you earn. Income is capped by your hours.
Agency
You sell a team's time and keep a margin on each hour, so income is no longer limited by your own hours.
Productized service
You sell a fixed outcome at a fixed price. Your process, not your hours, sets the margin.
Software product
You sell software many times over. Income is least tied to time, but it takes longest to build.
Chapter 10
Market size
Investors and business owners size a market in three layers. Knowing them helps you check whether a niche can support the income you want.
TAM
Total addressable market
All the money spent each year on the kind of service you offer, if you could sell to everyone.
SAM
Serviceable addressable market
The part of TAM you can actually reach, given your niche, language, region and delivery capacity.
SOM
Serviceable obtainable market
The share of SAM you can realistically win in the next few years, given competition.
The global picture, 2026
| Market | Size | Growth | Source |
|---|---|---|---|
| Worldwide IT spending | $6.37 T | +14.2% | Gartner, Jul 2026 |
| AI spending about 56% of it on infrastructure | $2.7 T | +49.5% | Gartner, Sep 2026 |
| IT services | > $1.8 T | – | Gartner, 2026 forecast |
| Software spending | $1.47 T | +15.5% | Gartner, Jul 2026 |
| Cloud infrastructure (IaaS) | $287 B | +29.3% | Gartner, Jul 2026 |
| Information security | ≈ $249 B | +12.7% | Gartner, 2Q26 forecast |
| India tech industry revenue IT services $149 B · exports $246 B | $315 B | +6.1% | NASSCOM, FY2026 |
| US skilled independent workers' earnings 20 million+ people | $1.5 T | – | Upwork, 2024 data |
On the supply side, SlashData counts about 47.2 million developers worldwide, 36.5 million of them professionals (early 2025).
One ten-millionth of global software spending is $147,000 a year. The market is never too small for one person or a small agency. What limits you is how many buyers you can reach and whether they choose you, which is what SAM and SOM measure.
Sources: Gartner IT spending (Jul 2026) · Gartner AI spending (Sep 2026) · Gartner security forecast summary · NASSCOM FY2026 · SlashData developer population · Upwork Future Workforce Index
Chapter 11
Supply, demand & income
Prices rise where demand is strong and skilled people are scarce, and fall where many people can do the work. The last column rates how well each field can be run as your own business: solo or with a small team, remotely, without large capital, selling directly to clients.
| Field | Demand signal | Talent supply | US median pay (employed) | Own-business rate | Autonomy fit |
|---|---|---|---|---|---|
| Web & app development | Web developer jobs +8% (2024–34) | Crowded | $90,930 web devs, 2024 | $50–150/h | High |
| Software & backend | Software developer jobs +15–16% (2024–34) | Balanced | $135,980 2025 | $100–200/h | High |
| Cloud & DevOps | IaaS spending +29% in 2026 | Senior talent scarce | – | $100–200/h | High |
| Data science & engineering | Data scientist jobs +34% (2024–34) | Balanced | $120,230 data scientists, 2025 | $100–200/h | High |
| AI engineering | AI spending +49.5% in 2026 | Scarce for production work | – | $120–250/h | High |
| Security | Security analyst jobs +29% (2024–34) | Scarce | $129,180 2025 | $120–300/h | High |
| Embedded & IoT | Growing with connected devices | Scarce | – | $90–180/h | Medium |
| Games & graphics | Hit-driven and uneven | Crowded | – | Varies widely | Medium |
| OS, compilers, databases, HPC | Concentrated in large firms | Very scarce | – | Niche consulting | Low |
| Trading & safety-critical | Niche, well funded | Very scarce | – | Mostly employed | Low |
Supply pills show the market from your side: green means few competitors. Pay figures are BLS medians for the closest occupation; "–" means BLS has no separate category. Own-business rates are indicative ranges; see Chapter 13 and the agency handbook.
Where the opportunity is
The best fields for autonomy combine strong demand, scarce talent and a high autonomy fit: cloud and DevOps, data, AI integration and security. They also stack naturally on web and app work. Clients who hire you to build their product will need hosting, data, AI features and security next.
AI coding tools are pushing down the price of simple, repeatable work such as basic landing pages and standard CRUD apps. Protect your rates by selling outcomes rather than hours, specializing in a niche, and handling the integration and judgment work that tools can't do alone.
Sources: BLS software developers · BLS web developers · BLS information security analysts · BLS data scientists
Chapter 12
Size your niche
Estimate TAM, SAM and SOM for a specific niche and check whether it can support your income goal. The example is independent dental clinics in one country; replace it with your own niche.
If SOM falls short of your goal, you can raise the deal value (add services or care plans), widen the niche (a neighboring industry or another region), or improve reach (partners and referrals). Each of these moves one input in the calculator.
Chapter 13 · Part III
Higher-value services
Deeper engineering skills let an agency sell services that fewer competitors can offer, usually at higher rates and to larger clients. Rates are indicative for experienced specialists and vary by region.
| Service | Typical engagement | Rate (USD / h) | What makes you credible |
|---|---|---|---|
| Cloud migration & DevOps setup | Move to AWS / GCP / Azure, set up CI/CD and infrastructure as code | 100–200 | Cloud certifications, Terraform and Kubernetes work |
| Performance engineering | Profile and speed up slow systems and databases | 120–220 | Before-and-after numbers from past work |
| Data engineering | Pipelines, warehouses, dashboards | 100–200 | SQL depth, dbt, Airflow, Spark projects |
| AI & ML engineering | AI features, retrieval systems, evaluation, model deployment | 120–250 | Shipped AI features with measured quality |
| Security audits & hardening | Code review, threat modeling, authorized penetration testing | 120–300 | OSCP or similar, published findings, references |
| Legacy modernization | Rewrite or gradually replace old systems | 100–200 | Case studies of zero-downtime migrations |
| Embedded & IoT | Firmware, device connectivity, companion apps | 90–180 | Hardware projects, knowledge of relevant standards |
| Fractional CTO | Part-time technical leadership for startups | 150–350 | Years of senior or leadership experience |
These fit naturally on top of web and app work. A client whose app you built will often need cloud, data or AI work next, so each deeper skill becomes a new retainer.
Chapter 14
Roadmap from web dev
A suggested order for going deeper. Each stage builds on the previous one. Expect each to take 1–3 months of steady part-time study alongside client work.
Programming fundamentals
Learn a second language with a different model from JavaScript, such as Go, Rust or Java. Study data structures and algorithms properly.
Backend depth
Database indexes, transactions and isolation levels; HTTP in detail; caching; background jobs and queues.
Systems
How operating systems manage processes, threads, memory and files. How networks move data: TCP/IP, DNS, TLS.
Cloud & operations
Linux, Docker, Kubernetes basics, Terraform, CI/CD pipelines, logs, metrics and tracing.
Distributed systems & system design
Replication, partitioning, consensus, and designing systems for scale and failure.
Specialize
Pick one deep field from Chapter 02 that interests you and has client demand, and go all the way down.
Chapter 15
Practice projects
Build these to learn by doing. Each one follows a stage of the roadmap. Your progress is saved in this browser.
0 of 0 projects done
Stage 1–2 Fundamentals & backend
Stage 3 Systems
Stage 4 Cloud & operations
Stage 5–6 Distributed systems & specialization
Chapter 16
Reading list
Well-regarded books and courses, grouped by topic. Items marked free are available online at no cost.
- Designing Data-Intensive Applications
- Martin Kleppmann. The standard introduction to databases, replication and distributed data systems.
- Operating Systems: Three Easy Pieces free
- Remzi and Andrea Arpaci-Dusseau. A clear, practical OS textbook. pages.cs.wisc.edu/~remzi/OSTEP
- Computer Systems: A Programmer's Perspective
- Randal Bryant and David O'Hallaron. How programs actually run on hardware.
- Computer Networking: A Top-Down Approach
- James Kurose and Keith Ross. Networking from HTTP down to physical links.
- The Algorithm Design Manual
- Steven Skiena. Practical algorithms with real-world war stories.
- Crafting Interpreters free
- Robert Nystrom. Build two complete interpreters step by step. craftinginterpreters.com
- Site Reliability Engineering free
- Google. How large production systems are run. sre.google/books
- A Philosophy of Software Design
- John Ousterhout. Managing complexity in code and module design.
- Teach Yourself Computer Science free
- A curated self-study plan covering the nine core subjects. teachyourselfcs.com
- MIT 6.5840 Distributed Systems free
- Lectures, papers and labs including Raft. pdos.csail.mit.edu/6.824
- Nand2Tetris free
- Build a computer from logic gates up to an operating system. nand2tetris.org
- Harvard CS50 free
- A broad introduction to computer science, good for filling gaps. cs50.harvard.edu