40,000 Lines of PHP, One Server, $105K/Month

A single PHP file running on one dedicated server can generate over $100,000 per month in revenue. Pieter Levels has been doing it with photoai.com, and the whole internet found out today because Claude Code pushed a syntax error to production.

The Error Heard Round the Internet

Levelsio posted a screenshot to X with one word: “CLAUDEEEEEEEEEEEEEEEEEEE.” The screenshot showed photoai.com displaying a raw PHP parse error: Unmatched '}' in /srv/http/photoai.com/app/index.php on line 29825. A coding mistake, pushed live by Claude Code, visible to the entire internet.

Within minutes, developer Twitter did what developer Twitter does. Someone named Jonah quote-tweeted: “29k+ lines of php in 1 file. this guy is richer than me. fml.” That post alone got hundreds of thousands of views.

Then Pieter leaned into it. Instead of being embarrassed, he revealed the full picture. photoai.com is a 40,870-line file called index.php. $105,000 per month in revenue. $80,000 per month in profit. He posted a screenshot of the file’s last line: 40,870. benchmark(); followed by ?>.

“It was down for 2 seconds guys, oh no mah 99.999999%,” he joked.

The mass confusion was immediate. Engineers who’ve spent years decomposing monoliths into microservices and debating service mesh topologies were staring at a single PHP file that out-earns most of their companies.

One Developer, One AI, 40,000 Lines

Here’s the part that most of the discourse missed. Levelsio isn’t just a guy with a PHP file. He’s a solo developer using Claude Code to build and maintain a 40,000-line codebase. The error itself tells that story. His “ALWAYS PUSH” instruction to Claude Code overrode his “always test with php -t before pushing” rule. Classic AI agent problem: conflicting instructions, the agent picks one, and suddenly your parse error is in production.

But zoom out from the bug. One person is building, maintaining, shipping, and operating a product that generates $1.2 million a year. Five years ago, that codebase would’ve needed a small team. Backend engineers, a frontend person, someone doing deploys. Now it’s one guy and an AI coding agent.

That changes the infrastructure calculus completely. If your entire engineering organization is one person and an AI pair programmer, you don’t need infrastructure designed for a 20-person team. You don’t need the deploy pipeline, the staging environments, the microservice boundaries that exist primarily to let multiple teams work without stepping on each other. All of that coordination overhead disappears when there’s nobody to coordinate with.

We work on AI-driven development tooling ourselves, so this isn’t abstract to us. The shift toward agentic coding, where AI handles large chunks of implementation while a human steers, is real and accelerating. It compresses team sizes. And compressed teams need compressed infrastructure.

Should Pieter have caught that parse error before it went live? Sure. But his site was down for two seconds, he makes $80K/mo profit, and the incident became free marketing that got over a million views. The risk tolerance math is different when you’re a solo operator versus running a bank.

The Margins Tell the Story

photoai.com runs on what’s almost certainly a Hetzner dedicated server. Deployment is probably git pull or maybe even sftp. No container orchestration, no managed Kubernetes cluster, no three environments with matching infrastructure.

$105K revenue. $80K profit. That’s 76% margins.

You do not get 76% margins running the same application on AWS with EKS, RDS, ElastiCache, CloudFront, and a monitoring stack that costs more than the server it’s monitoring. (If you want to see what over-engineering looks like in practice, check out AWS’s official reference architecture for WordPress. Nine managed services to run a blog.) A beefy Hetzner dedicated box costs maybe $50 to $100 a month. His entire infrastructure bill is probably less than what most startups pay for their Datadog subscription.

And this is the part people get wrong. They look at photoai.com and think “well, it’s a small app.” It’s not small. It’s 40,000 lines of code serving enough users to generate six figures monthly. It’s a real product with real traffic. It just doesn’t need the infrastructure that the industry has convinced itself is mandatory.

Why This Works for MRR Businesses

There’s a specific reason simple infrastructure works so well here, and it’s not just about being small or scrappy.

photoai.com is a subscription business. Monthly recurring revenue. Subscribers sign up, they use the product, they pay every month. The traffic patterns are predictable. There are no Black Friday spikes, no viral launch days that 10x your load for 48 hours (well, except when Claude Code takes you down and a million people visit to see the error page).

The entire selling point of elastic cloud is “scale up and down with demand.” But when your demand is steady, you’re paying a premium for elasticity you never use. Cloud vendors charge enormous margins for the ability to burst. If you never burst, that’s just a tax.

MRR businesses with steady subscriber bases have predictable infrastructure needs. Predictable needs mean you can provision exactly what you need. And when you can provision exactly what you need, a dedicated server at a fraction of the cloud price makes a lot of sense. The business model and the infrastructure model are in alignment.

This isn’t unique to photoai.com. Plenty of SaaS products and subscription platforms have the same profile. Steady traffic, predictable growth. These are exactly the businesses that benefit most from simple, owned infrastructure.

When This Doesn’t Work

We’d be lying if we said everyone should throw their code in a single PHP file and call it a day.

Fifteen engineers all working on the same codebase need service boundaries so people can deploy independently. Financial transactions and healthcare data come with compliance requirements that change the equation. Traffic that genuinely spikes 50x unpredictably is where elastic infrastructure earns its keep. And if you need presence in multiple geographic regions for latency, a single box in Falkenstein isn’t going to cut it.

Most companies don’t have these constraints though. They pick their infrastructure based on what’s impressive on a conference talk or what looks good on an engineering blog post, not what the business actually needs. The default has become complexity when the default should be simplicity.

Start with the simplest thing that works. Add complexity when the business demands it, not when your ego does. Complexity is easy to add and brutal to remove. Anyone who’s tried to un-microservice a microservice architecture knows that.

Right-Sizing Is the Whole Game

Levelsio’s 40,000-line PHP file isn’t a best practice. It’s proof that best practices are context-dependent. For a solo developer with an AI coding assistant running a profitable subscription product, a monolith on a dedicated server is close to optimal. The margins speak for themselves, and the recovery time from an outage is “2 seconds.”

For a different company with different constraints, the right answer looks completely different. The skill is knowing which situation you’re actually in, not which one you wish you were in.

That’s what we spend our time on at Inspectural. Helping companies figure out where they sit on that spectrum. More often than we expected, the answer is: you need less than you think.