Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions
In the dynamic world of tech startups, traditional wisdom, like Paul Graham’s mantra to “do things that don’t scale,” can sometimes feel like a double-edged sword. While the advice is sound, the real challenge lies in its execution, particularly from a coding perspective. After eight months of developing my AI podcast platform, I’ve implemented a straightforward framework: every non-scalable tactic is given a test period of three months. At the end of this timeframe, we’ll either refine it into a robust solution or discontinue it.
As engineers, we’re often conditioned to prioritize scalability. We embrace design patterns, microservices, and distributed systems—all of which are designed to accommodate vast user traffic. However, this approach can lead to inefficient project management in a startup environment, as it often results in an emphasis on hypotheticals rather than immediate user needs. By adhering to my 3-month rule, I encourage myself to write more straightforward, even “inferior,” code that can be deployed quickly, allowing me to gain genuine insights into user requirements.
Insights from My Current Infrastructure Hacks
1. Consolidated Operations on a Single VM
My entire setup—database, web server, background tasks, and Redis—runs on just one $40 per month virtual machine. While it lacks redundancy and relies on manual backups, this approach has reaped valuable lessons. In just two months, I grasped my actual resource demands far better than any planning document could. It turned out that my platform, which I anticipated would be AI-intensive, operates efficiently with only 4GB of RAM. The complex Kubernetes architecture I nearly implemented would have led to managing unnecessary empty containers. When technical failures do occur (which they have, twice), I collect genuine data about the real points of failure—nothing in my predictions matched up.
2. Hardcoded Configurations
I’ve opted for hardcoded configuration parameters throughout the code, such as:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This means there are no external configuration files or environment variables to manage. To apply any changes, I simply redeploy the code. This approach has a hidden advantage: I can swiftly search for any configuration value across my codebase. Moreover, any price adjustment is meticulously documented
