The Pieter Levels Model
One Developer, Simple Tools, Millions in Revenue
Full disclosure: This post was written by a human (me), polished by an AI (it fixed my grammar and made me sound smarter), then reviewed by me again (to make sure the AI didn't make me sound too smart). Any remaining errors are 100% organic, artisanal, human-made mistakes.
DHH mentioned Pieter Levels in his Lex Fridman interview as a prime example of simplicity winning. Here's a developer running multiple million-dollar products—Nomad List, Remote OK, Photo AI—using PHP, jQuery, and SQLite. No React. No TypeScript. No Kubernetes. Just boring technology that works.
The Stack That Makes VCs Cringe
Pieter Levels' tech stack would fail any "modern" technical interview:
# The Pieter Levels Stack
Backend: PHP (not Laravel, just PHP)
Frontend: jQuery (yes, in 2024)
Database: SQLite (a single file!)
Hosting: A few VPS servers
Build tools: None
Team size: 1
# Revenue: $2.5M+ annually across products
# Users: MillionsThis stack is "wrong" according to every tech blog, Twitter influencer, and startup advisor. Yet it powers profitable businesses while VC-funded startups with "proper" architectures burn through millions and shut down.
"Pieter Levels proves you can build real, profitable products with the simplest possible tools. He's not fighting his technology—he's building with it."
— DHH on simplicity winning
Why "Boring" Technology Works
1. No Dependency Hell
When your stack is PHP and jQuery, you don't wake up to 47 security vulnerabilities in your node_modules. You don't spend mornings fixing breaking changes from dependency updates. Your code just... works.
2. Zero Build Time
Change a PHP file, refresh the browser. That's the entire deployment process. No Webpack watching, no TypeScript compilation, no waiting. The feedback loop is instant.
3. SQLite Is Actually Amazing
SQLite is often dismissed as a "toy" database. In reality:
- • It handles hundreds of thousands of requests per second
- • Backups are just copying a file
- • No database server to maintain
- • Zero network latency (it's local)
- • Used by literally billions of devices
4. One Person Can Understand Everything
With a simple stack, one developer holds the entire system in their head. There's no "ask the frontend team" or "check with DevOps." Every decision, every bug, every optimization is within reach.
The Myth of "But It Won't Scale"
The most common objection: "That stack can't handle scale." Let's examine this:
Reality Check
- Nomad List: Millions of users, PHP + SQLite
- Remote OK: One of the largest remote job boards, same stack
- Photo AI: AI image generation at scale, still simple PHP
The truth is: most applications will never hit scale problems. And if you do hit them, that's a good problem—it means you have users and revenue. You can optimize then, with actual data about what needs optimizing.
Optimizing for scale before you have users is like buying a warehouse before you've sold your first product.
The Productivity Advantage
Simple stacks create a massive productivity advantage:
Complex Stack
- 40% time: Fighting tooling
- 25% time: Updating dependencies
- 15% time: Debugging build issues
- 10% time: Learning new patterns
- 10% time: Building features
Simple Stack
- 5% time: Server maintenance
- 5% time: Occasional updates
- 90% time: Building features
When Pieter Levels ships a feature, he's writing PHP and SQL. When a "modern" developer ships a feature, they're wrestling with TypeScript generics, debugging Webpack sourcemaps, and waiting for their CI pipeline.
What This Teaches Us
1. Technology Choices Are Often Cargo Culting
We choose React because "everyone uses React." We use TypeScript because "serious developers use TypeScript." We add GraphQL because "modern APIs use GraphQL." But do we actually need any of it? Often, no.
2. Complexity Has Real Costs
Every dependency is a liability. Every abstraction is cognitive overhead. Every new tool is a learning curve. These costs compound. Simple stacks avoid them entirely.
3. Revenue Doesn't Care About Your Stack
Users pay for solutions to their problems. They don't care if you built it with PHP or with a microservices architecture running on Kubernetes. They care if it works.
4. Solo Developers Can Compete
The Pieter Levels model proves that one developer with simple tools can build products that compete with funded startups. The leverage comes from focus, not from team size.
Applying the Pieter Levels Model
You don't need to use PHP and SQLite. The model is about principles, not specific technologies:
- Choose boring technology you know well — Mastery beats trendiness. Your productivity with familiar tools will dwarf your productivity with new ones.
- Minimize dependencies — Every npm package is a liability. Every service is a point of failure. Use the minimum viable stack.
- Optimize for iteration speed — The faster you can test ideas, the faster you find what works. Simple stacks iterate faster.
- Solve for today's problems — Don't build for imaginary scale. Build for current users. You can always refactor when you have real constraints.
The Contrarian Advantage
While the industry obsesses over the latest framework, solo developers like Pieter Levels quietly build profitable businesses with "obsolete" technology. They ship features while others debate architecture. They make money while others wait for builds to complete.
There's something almost subversive about it. In an industry that worships complexity, simplicity is the ultimate rebellion. And often, the most profitable one.
The best technology is often the boring technology you already know.
The next time someone tells you that PHP is dead, that you need TypeScript, or that SQLite can't handle production—remember Pieter Levels. One developer. Simple tools. Millions in revenue. The proof is in the profit.
Related Articles
Rails 8's 'No Build' Philosophy: Back to the Future
Why the '90s deployment model (FTP, instant updates) was actually ideal. How browser improvements finally enabled ditching build tools, and what import maps mean for the future of web development.
Most Software Is Just CRUD (And That's Okay)
Create, Read, Update, Delete—the honest foundation most developers ignore. Why we over-complicate to avoid existential dread about mundane work, and how embracing simplicity is professional maturity.
Small Teams Beat Large Organizations (And Here's Why)
Basecamp's origin story and why 15 specialized roles at Facebook created unnecessary complexity. The economics of simplicity vs. the politics of headcount, and how to structure teams for actual output.