ENTREPRENEURSHIPWeeks to result

The Radical Simplicity Stack

Use boring technology and minimal tools to maximize output and profit

Problem it solves

business growth stalls

Best for

Solo founders and small teams who want to build profitable products without the overhead of complex modern technology stacks.

Not ideal for

Teams building highly complex applications that genuinely require microservices, or companies that need to hire from a large talent pool using popular frameworks.

Overview

Why this framework exists

The Radical Simplicity Stack is an approach to technology selection that deliberately chooses the simplest, most boring, and most proven tools available rather than chasing the latest frameworks and architectures. Pioneered by indie hackers like Pieter Levels, this philosophy argues that technology complexity is the enemy of solo founders and small teams. By using vanilla PHP, simple JavaScript, SQLite databases, and basic server setups, you eliminate entire categories of problems: dependency management, build tooling, deployment complexity, and hiring difficulties. The result is products that are cheap to run, easy to maintain, and fast to iterate on. The framework challenges the assumption that modern web development requires React, TypeScript, Docker, Kubernetes, and cloud-native architectures. For most products, especially those generating under $10M in revenue, simple technology works perfectly fine and lets you focus on what matters: solving customer problems.

Core principles

5 total
  1. Choose technology you already know over technology that's popular
  2. Minimize dependencies to minimize potential points of failure
  3. Server costs should be trivial relative to revenue
  4. If a solo developer can't understand the entire stack, it's too complex
  5. Boring technology is battle-tested technology

Steps

3 steps
  1. Audit your current tech stack for unnecessary complexity
    List every technology, framework, library, and service your product depends on. For each one, ask: does this directly help me serve customers, or does it exist to manage complexity created by other tools? If a tool exists primarily to manage other tools (build systems, orchestration layers, etc.), it's a candidate for elimination.
    Pro tipCount your node_modules or equivalent dependency tree. If it's in the thousands, you have a complexity problem.
  2. Replace complex tools with simpler alternatives
    For each unnecessary complexity you identified, find the simplest replacement. Replace complex ORMs with raw SQL queries. Replace React with server-rendered HTML and vanilla JavaScript. Replace Kubernetes with a single VPS. Replace microservices with a monolith. The goal is to reduce the total number of moving parts while maintaining the same user-facing functionality.
    Pro tipSQLite can handle far more traffic than most people think—often millions of requests per day on modest hardware.
    WarningDon't rewrite everything at once. Simplify incrementally, starting with the components that cause the most maintenance burden.
  3. Optimize for developer speed, not theoretical scalability
    Make decisions based on how fast you can ship features, not how well the system would handle millions of users you don't have yet. Choose tools that let you go from idea to deployed feature in hours, not days. If your deployment process takes more than 5 minutes or requires multiple steps, simplify it.
    Pro tipA simple git push deploy to a single server beats a complex CI/CD pipeline for solo founders.

Checklist

Saved in your browser

Examples

1 cases
Pieter Levels running multi-million dollar businesses on PHP

Pieter Levels runs Nomad List, Remote OK, and other products generating millions in combined annual revenue using PHP, jQuery, and simple server setups. His entire infrastructure costs are minimal compared to VC-funded startups running similar products on complex cloud architectures with large engineering teams.

OutcomeOver $3M annual revenue with near-zero infrastructure costs and no employees, proving that technology simplicity scales.

Common mistakes

2 traps
Premature optimization for scale
Building for millions of users when you have dozens is the most common mistake. Complex architectures designed for scale create massive overhead in development speed, debugging difficulty, and operational costs. Scale when you actually need to, not before.
Resume-driven development
Choosing technologies because they look good on a resume rather than because they're the right tool for the job. As a solo founder, nobody is reviewing your code. The only metric that matters is whether the product works and makes money.

Origin story

How this framework came to be

Pieter Levels built Nomad List and Remote OK using PHP and jQuery at a time when the tech world was obsessed with single-page applications and complex JavaScript frameworks. Many developers mocked his tech choices, but his businesses generated millions in revenue with near-zero infrastructure costs and no employees. His approach proved that technology choice is almost irrelevant to business success, and that simplicity is actually a competitive advantage for solo founders who need to move fast and keep costs low.

Source

Traced to primary
Source · PODCAST
This Is What Real Freedom Looks Like
Pieter Levels · 2022
Open source →