Pieter Levels’ (@levelsio) "Solopreneur" Approach: A Lesson in Context for Developers
Co-Founder / CEO
Pieter Levels (@levelsio) is a famous solo entrepreneur. He caused a stir in the tech community by appearing on Lex Fridman’s YouTube channel. During the interview, Pieter discussed his tech stack. He also explained how he builds his software products. This sparked much debate among developers. Some argued his approach was right. Others claimed it was wrong. But here’s the thing: there’s no universal “right” or “wrong” in software development. What matters is what works best for your situation.
In the software world, it’s easy to fall into a black-and-white mindset. We often see things as either perfect or flawed. But the reality is much more complex. Technology choices and development practices are a gray area. What works in one context might fail in another.
Here’s one take:
Going on the record to say @levelsio method of writing software is based af and we can all learn from how he prioritizes delivery over everything else
— Theo - t3.gg (@t3dotgg) August 22, 2024
Here’s another:
no. he’s not an “absolute chad” he’s a liability. idk why anyone would see this as a good thing. it really shows he cares more about money than he does about writing good code. https://t.co/Psnjom19aH
— luna (@ImLunaHey) August 21, 2024
Deploying straight to production
Lex, the interviewer:
You don’t have a testing ground?
Pieter:
No. I’m too lazy to setup a staging server so nowadays I just deploy to production…Look it’s idiotic at any big company. But for me it works.
During the interview, Lex asked Pieter if he uses a testing environment. Pieter’s response? “No. I’m too lazy to set up a staging server, so I just deploy to production… It’s idiotic at a big company, but it works for me.”
Pieter’s point is important. What works for one developer might not work for another. Everyone’s context is unique. Pieter’s approach works. He’s running a small operation. He can quickly fix issues as they arise. For larger teams or businesses, deploying directly to production could lead to chaos. It’s all about the context.
No staging environment
Let’s take another example: not having a staging environment. This might sound like a bad idea to many developers, but in some cases, it’s actually beneficial. I once worked as a Fractional CTO for a small company with just two developers and a few users. They had four separate environments—local, dev, staging, and production. Every change had to go through each environment. This slowed down development, making it hard to quickly release changes.
We decided to simplify. We introduced feature flags. They let developers push changes to production but keep them hidden until ready. It sped up deployment times. The team could now move faster and test in the real world. This approach wouldn’t work everywhere. But, it was perfect for that situation.
Understanding the context
One of the best things we can do is discover the context on a specific solution. What problem was the solution designed to solve? The solution can be a process or technology. Take the process that Pieter uses. The problem it solves is getting process out of the way for a one-person team (or very small team) to rapidly iterate. Is the problem you are trying to solve the same problem? Perhaps you just like what Pieter is doing and want to adapt it at your company. Is your context the same? Is this a solution in search of a problem? This is not to say that we can’t learn from Pieter’s solution. Perhaps some or all of it makes sense for your company. But we can only know that if we understand both our own context and the context the solution was created for.
The Problem with Being Dogmatic About Tech
Pieter provides his “most controversial” take here:
There’s frameworks now that raise money. They raise a lot of money. $50M, $100M, $3M dollars. And the idea is you need to make the developers the “new developers.” Like when you’re 18 or 20 years old, right? Get them to use this framework and add a platform to it. It’s open-source, but you probably shgould use the platform, which is paid. The cost of the platforms to host it are 1,000 times higher than just hosting it on a simple AWS server or VPS on Digital Ocean. So there’s obviously a monitary incentive. We want to get a lot of developers to use this technology and then we’re going to charge them money. They will use it in startups and then the startups can pay the bills. But it kind of destroys the information out there about learning to code because they pay YouTubers, influencers, developers influencers. The same thing happens in nutrition and fitness. They pay developers to promote ths tuff and make demo products with it. And I started noticing this because when I would ship my stuff, people would say, what are you using? I would say, PHP, jQuery, why does it matter? People would start attacking me. Why are you not using this new technology? This new framework. This new thing. And I said, I don’t know? Because this PHP thing works. And I’m not really optimizing for anything. It just works. I understand there are new technologies that are better and they should be an improvement. I’m very suspcious of money. Just like lobbying. There’s money in this development framework scene. There’s hundreds of millions that goes to ads or influencers or whatever.
Pieter also noted a problem. “Framework developers” now rely too much on trendy, marketed tools. Many frameworks today are backed by VC and heavily marketed. This can distort decision-making. Developers may feel pressured to adopt these tools. But simpler, established tech might work just as well.
Being too attached to a framework or technology can limit your growth as a developer. We must view technologies as tools to solve problems, not as universal solutions. There’s nothing wrong with sticking to what you know. But it’s also valuable to explore new options and stay open to alternatives. This lets you decide based on your project’s needs, not trends.
Conclusion
In software development, there is rarely a “right” answer that fits all situations. Every decision depends on context, scale, and specific needs. We should not see technology choices as black and white. Instead, we should embrace the nuances and adapt our strategies. By doing so, we can build better products and avoid the pitfalls of dogmatic thinking.
