Embracing the 3-Month Rule: A Framework for Unscalable Coding
In the realm of startup culture, one piece of advice often reverberates: “Do things that don’t scale,” as famously advocated by Paul Graham. However, the challenge lies in translating this principle into actionable steps, especially within the context of software development. After dedicating eight months to the creation of my AI podcast platform, I devised a pragmatic approach: any non-scalable solution is granted a three-month lifespan. By then, it either demonstrates its worth and evolves into a robust structure, or it is relegated to the archives.
Understanding the Trade-offs of Scalability
As developers, we are naturally inclined to craft highly scalable solutions from the outset. We envision intricate design patterns, microservices, and distributed architectures capable of handling millions of users—a mindset fundamentally rooted in established corporate practices. However, within a startup ecosystem, these aspirations can transform into costly procrastination, leading to premature optimizations for imaginary users and fictitious challenges. By adhering to my three-month rule, I’m compelled to focus on creating straightforward, even “imperfect,” code that facilitates rapid deployment and uncovers the genuine needs of my users.
Current Hacks in My Infrastructure: A Strategic Choice
1. Consolidated Operations on a Single VM
Currently, my entire setup—database, web server, background jobs, and caching—is running on one $40/month virtual machine. No redundancy, no complex configurations—just manual backups to my local drive. This simplicity has granted me invaluable insights into my actual resource requirements in just two months. For instance, I’ve discovered that my “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes architecture I nearly implemented would have led to managing empty containers. Each crash (which has happened twice) provides concrete data on points of failure, often revealing surprises that challenge my expectations.
2. Hardcoded Configuration Values
Configuration values are literally hardcoded into the codebase:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no separate configuration files or environment variables; instead, constants are interspersed throughout the code. While some may view this as sloppy, it holds hidden efficiency. I can quickly search my entire codebase for configuration values, and each update is tracked
