Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the startup world, we frequently hear about the importance of doing things that don’t scale, a concept popularized by Paul Graham. However, executing this advice in practice—especially from a technical standpoint—can often be overlooked. After dedicating eight months to developing my AI podcast platform, I’ve established a straightforward methodology: every unscalable approach is granted a three-month trial period. If it proves beneficial, it receives the refinement it deserves; otherwise, it is retired.
As engineers, we are conditioned to prioritize scalable architecture from the outset. Concepts like design patterns, microservices, and distributed systems may seem alluring, especially for applications that need to accommodate millions of users. However, in the startup environment, focusing solely on scalability can lead to unnecessary delays and wasted resources. By adhering to my three-month rule, I am compelled to produce straightforward, pragmatic code that facilitates immediate learning about user needs.
Smart Hacks in My Current Infrastructure
1. Consolidated Operations on a Single VM
I’ve opted to run my database, web server, background jobs, and caching on a single virtual machine for just $40 a month—no redundancy and manual backups.
The insight gained here has been invaluable; within two months, I have a clearer understanding of my actual resource demands compared to any theoretical capacity planning documents. My “AI-centric” platform only peaks at 4GB of RAM, and the complex Kubernetes setup I nearly pursued would have resulted in managing idle containers. When this VM crashes—something that has happened twice—I obtain concrete data about the actual points of failure, which often surprise me.
2. Hardcoded Configuration Throughout
All configurations are hardcoded directly within the codebase:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no configuration files or environment variables; any modifications require a redeployment.
The advantage here? I can swiftly search the entire codebase for any configuration value, and every change is logged in Git history. The time invested in this approach is trivial compared to the prolonged development of a configuration service, which I would only have utilized three times in three months.
3. Using SQLite for Production
Surprisingly, I’m employing SQLite for my multi-user
