Who Are You Scaling For?

Who are you scaling for?
In the AI age, the name of the game is not building a SaaS with 100,000 users. It's building a fully functioning company for six or eight people. One server can host 100,000 users. One GPU cannot. At The Vibe Jam, we build with jQuery and SQLite, store a password hash, skip the username, and whitelist IPs. Scaling up is 6 prompts away. Paul Graham said do things that don't scale. He was right.
Everyone keeps asking the same question: "Will it scale?"
Wrong question.
The right question is: who are you scaling for?
Netflix handles 200 million users. YouTube serves 2 billion. The infrastructure behind those platforms is astonishing -- globally distributed CDNs, custom load balancers, terabytes of cache, thousands of engineers maintaining the machine.
You are not Netflix. You are not YouTube. And here's the part nobody wants to say out loud: in the AI age, you don't need to be.
The name of the game is not building a SaaS. It's building a fully functioning company. And a fully functioning company does not require a hundred thousand users. It requires the right six.
You Don't Need All That

Restraint is architecture. Build less. Build better.
Here's a thought experiment: what if you built software for six people?
Not a hundred. Not a thousand. Six. Maybe eight if you're feeling ambitious.
Six people who need a tool. Six people whose workflow you understand deeply because you've sat across the table from them. Six people who will tell you exactly what's broken because they're not filing support tickets -- they're sending you a text.
The things that Netflix and YouTube do to handle scale are not things you need to take into consideration. Horizontal autoscaling. Blue-green deployments. Multi-region failover. Those are solutions to problems you do not have.
Powerful AI systems don't need to be operated by hundreds of thousands of users. As a matter of fact, the architecture doesn't support it.
The GPU Problem

One server hosts 100K users. One GPU does not.
Here's a fact that changes the math on everything: one server can host 100,000 users. One GPU cannot.
Traditional web applications are I/O bound. A request comes in, hits a database, returns a response. The server barely breaks a sweat. You can run a blog, a SaaS dashboard, and an API on the same $20/month box and nobody notices.
AI inference is compute bound. Every request burns GPU cycles. Every token costs real electricity. The ceiling is hard and it's low compared to traditional web serving. A single GPU might handle a few dozen concurrent inference requests before it's saturated.
So why are we building AI-powered tools like we're building the next Twitter? The architecture literally doesn't support mass-consumer scale. What it does support is small, focused, powerful tools that supercharge the humans who use them.
Build tools for six humans. That's the sweet spot.
jQuery, SQLite, and a Password Hash

A password hash is a one-way scramble. Same principle as Gmail. Simpler foundation.
At The Vibe Jam, we've had a ton of luck with jQuery and SQLite.
Not React. Not Postgres. Not a managed auth service with a monthly bill. jQuery and SQLite.
We store a password hash to let people in. That's it.
What is a password hash? Think of it like a one-way grinder. You put your password in the top, turn the crank, and a scrambled version comes out the bottom. The scrambled version is what gets stored -- never the original password. When you log in, the system runs your password through the same grinder and checks if the scrambled output matches what's on file. The original password is never saved anywhere. This is exactly how it works at Google, at Netflix, at every login on the planet. We just do it on a simpler foundation.
An app doesn't even need a username. Can you believe that? If security becomes a concern, whitelist IP addresses. A small app is even more secure than a big app -- less surface area, fewer endpoints, fewer attack vectors. The simplest solution is usually the safest.

Two tools. One finished product. That's the whole stack.
Most of the internet still runs on jQuery. The AI has had way more experience writing it than any modern framework. It doesn't need to manage a complex dependency tree. There are no breaking changes from last week's release. It just works -- and the AI writes it fluently because there's more jQuery training data than anything else.
Transcripts, Not Overviews

The input is a real conversation. The output is everything you're reading.
Here's where the content comes from. Not AI-generated overviews. Not ChatGPT summaries. Transcripts.
We schedule a meeting once a week. Pick five topics. Talk about them. Record it. That transcript -- raw, unpolished, full of actual human thinking -- gets fed into the machine and comes out the other end as blog posts, social campaigns, the whole pipeline.
Very much like the content you are reading right now.
Do your own dissecting of the prompts. The AI is powerful at turning your voice into distribution, but only if you give it your actual voice. An AI overview is a summary of everyone else's ideas. A transcript is yours.
Scaling Is Six Prompts Away

When the time comes, just open the door.
I always get the pushback: "You're going to need something that scales a little better."
I agree. But here's the thing: scaling up is only six or eight prompts away.
Of course we need to switch to Postgres eventually. But once the database moves elsewhere, it's less under the AI's control. Right now, with SQLite sitting right there in the project, the AI has full control of everything. It doesn't have to use an MCP server to do table migrations. It can modify the schema, update the queries, and test the result in one loop. You can think of new ideas at a much more rapid rate.
If you just make everything operate in one closed-knit environment, the AI has full control. And that's exactly the point. Build small. Iterate fast. When the time comes to scale -- and you'll know when -- it's a few conversations with your AI editor, not a six-month engineering project.
Do Things That Don't Scale

Tend your garden. The rest will follow.
Paul Graham wrote the famous essay "Do Things That Don't Scale" back in 2013. Brian Chesky lived it -- hand-delivering Airbnb listings, personally photographing every apartment, doing things that would never work at a million users. But that's how he got to a million users.
The lesson hasn't changed. OpenAI is very powerful, but learning to vibe code is way more powerful than that. Because vibe coding isn't about the model -- it's about keeping the human in control. It's about building something small and real and useful for a few people who matter, instead of building something big and abstract and theoretical for a crowd that doesn't exist yet.
Build for six humans. Use jQuery. Use SQLite. Store a password hash. Skip the username. Whitelist IPs. Keep it all in one place where the AI can see everything.
Then scale when the time comes. It's only six prompts away.
Vibeforth.
Learn how at The Vibe Jam.

Chris Johnston
Chris Johnston is the founder of PostScarcity AI and The Vibe Jam. Former development agency leader who managed 8 agile teams for venture-backed clients. Now teaching non-technical people to build with AI through vibe coding. Book a free Vibe Check to get started.
More About Chris Johnston