Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Coding
In the world of startups, the wisdom of Paul Graham to “do things that don’t scale” is frequently quoted but rarely unpacked, especially in the realm of coding. After dedicating the last eight months to building my AI podcast platform, I’ve devised a straightforward framework: every hack or shortcut I implement has a three-month lifespan. At the end of this period, it must either demonstrate its worth and be properly developed, or it faces elimination.
This philosophy represents a significant departure from conventional engineering practices, which often emphasize creating scalable solutions right from the outset. Engineers are trained to envision complex architectures—think microservices and distributed systems—that are designed to sustain millions of users. However, in the startup ecosystem, such scalability can frequently lead to wasted resources, as we’re often optimizing for non-existent users and hypothetical issues. My three-month rule compels me to prioritize straightforward, unrefined code that delivers results and reveals essential user insights.
Key Infrastructure Hacks: Insights from My Journey
1. Consolidated Infrastructure on a Single VM
Currently, my entire setup—including the database, web server, background jobs, and Redis—runs on a single $40/month virtual machine without any redundancy. While manual backups to my local machine might seem risky, this choice has proven to be incredibly informative. In just two months, I’ve gained insights into my actual resource utilization that far outweigh what traditional capacity planning might suggest. For instance, my “AI-centric” platform peaks at merely 4GB of RAM, debunking my prior assumptions about its requirements. Each time the system crashes (which has happened a couple of times), I gain valuable data about the real points of failure—often contrary to my expectations.
2. Hardcoded Configurations: A Hidden Gem
Instead of utilizing configuration files or environment variables, I’m employing hardcoded constants throughout my application:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this might appear outdated, it affords me a significant advantage—quick access to all configuration values across my codebase. Modifying any parameter means a straightforward redeployment, and changes are meticulously documented in my git history. Instead of spending weeks developing a dedicated configuration service, I’ve tweaked these values merely three times in
