Embracing the 3-Month Rule: A Practical Approach to Development Without Scale

In the tech world, Paul Graham famously advised, “Do things that don’t scale.” However, the challenge often lies in translating this advice into practical coding strategies. After eight months of developing my AI podcast platform, I’ve devised a straightforward framework to navigate the unscalable: every workaround or hack is allotted a mere three months to demonstrate its worth.

As engineers, we are instinctively drawn towards creating scalable solutions right from the onset. We envision ideal architectures with intricate design patterns, microservices, and distributed systems—tools that are optimal for managing vast user bases. This instinct, however, can lead us astray, especially in a startup setting where scalability often becomes a costly form of procrastination. Instead, I advocate for writing simpler, more direct code that is functional and that genuinely illuminates user needs.

My Current Infrastructure Strategies: Pragmatic Choices that Drive Learning

1. Consolidated Resources on a Single VM

All of my essential services—from the database and web server to background jobs and caching—operate on a single $40/month virtual machine. Yes, there’s no redundancy, and backups are done manually, but this setup has been enlightening. In just two months, I’ve gained better insights into my resource demands than through any sophisticated planning document. My platform, which I had initially categorized as “AI-heavy,” peaks at just 4GB of RAM. The complex Kubernetes infrastructure I once considered would have been managing unused containers.

When the system crashes (which has happened a couple of times), I receive immediate feedback on what truly fails—not what I assumed would break.

2. Unconventional Configuration Management

Instead of utilizing configuration files or environment variables, I’ve opted for hardcoded constants like:

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

While it may seem impractical, this approach reveals its benefits: I can quickly search my codebase for configuration values, and all changes are documented in my Git history. Over three months, I’ve only modified these constants three times, making the time spent redeploying negligible compared to the hours that could have gone into creating a separate configuration service.

3. Using SQLite in Production

Believe it or not, I am utilizing SQLite for my multi-user web application. My