Embracing the Unscalable: My 3-Month Framework for Learning Through Code

In the tech community, the phrase “Do things that don’t scale” by Paul Graham is a well-known axiom. However, the practical application of this advice, especially in software development, is often overlooked. After eight months of continuous development on my AI podcast platform, I’ve devised a straightforward framework: every non-scalable approach I implement has a lifespan of three months. At the end of this period, it must either demonstrate its value and be refined into a scalable solution or it will be phased out.

As developers, we are often conditioned to prioritize scalable solutions right from the outset. We become enamored with concepts like design patterns, microservices, and sophisticated distributed systems—all designed to support vast user bases. While this may be the mindset of larger corporations, in the startup world, focusing on scalability too early can lead us to expensive delays. Instead of solving existing problems, we might be preparing for hypothetical issues related to users who are currently non-existent. My three-month framework compels me to create straightforward and quick solutions—sometimes even “bad” code—that are directly actionable and reveal genuine user needs.

My Unconventional Infrastructure Decisions

1. Consolidating Everything on a Single VM

I run my entire infrastructure—a database, web server, background jobs, and Redis—on a single virtual machine that costs about $40 a month. This setup lacks redundancy and relies on manual backups to my local machine.

Why is this a wise choice? In just two months, I’ve gained invaluable insights regarding my actual resource requirements. For instance, my “AI-centric” platform only peaks at 4GB of RAM. The complex Kubernetes architecture I nearly adopted would have resulted in managing idle containers. Each crash (there have been two thus far) provides me with real data on the failure points, which are always surprising.

2. Using Hardcoded Configurations

My configuration values are directly coded into the application rather than stored in config files or environment variables. For example:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

This might seem counterintuitive, but it offers the advantage of rapid access. A quick grep allows me to find any configuration value instantly, and changes are easily tracked in Git history. Since I’ve only changed these