The 3-Month Rule: An Ingenious Framework for Unconventional Coding Strategies
In the world of technology, Paul Graham’s mantra, “Do things that don’t scale,” resonates strongly, yet the practical application of this wisdom in programming is often overlooked. As I recently embarked on the ambitious journey of developing my AI podcast platform over the past eight months, I established a straightforward principle: any temporary, non-scalable solution is limited to a three-month lifespan. After this period, the solution either demonstrates its worth and is refined into a robust feature, or it will be retired.
As engineers, we’re conditioned to prioritize scalable solutions from the outset—embracing design patterns, microservices, and distributed systems that support thousands, if not millions, of users. However, this “big company” mentality can hinder progress in a startup environment where scalable code may simply result in costly delays. By adhering to my three-month rule, I compel myself to write straightforward, sometimes imperfect code that is prompt to deploy and yields insights into what users truly require.
Current Infrastructure Hacks: Smart Choices for Learning
1. Single VM Setup
Currently, my entire infrastructure operates on a single virtual machine (VM) that costs just $40 a month, hosting everything from the database to background jobs without any redundancy. While this might seem like a reckless approach, it has granted me invaluable insights concerning my actual resource consumption in just two months. My so-called “AI-heavy” platform only requires 4GB of RAM at peak. Had I gone ahead with an elaborate Kubernetes setup, I would have ended up managing empty containers. And when issues arise (which they have), I gain firsthand knowledge about the true causes of failure—insights that are often surprising.
2. Hardcoded Constants
In my code, configuration values are hardcoded like this:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This means no external configuration files or environment variables. Any modification requires a redeployment, which might appear limiting, but there’s a silver lining. By running a simple search across my codebase, I can track changes in configuration quickly, all within seconds. In the three months that I have been operating this way, I have made only three changes in configurations, resulting in a mere 15 minutes of redeployment versus the 40 hours
One Comment
Thank you for sharing such an insightful breakdown of your approach with the 3-Month Rule. I appreciate how you emphasize the value of quick, tangible learning through non-scalable solutions—particularly in a startup context where speed often trumps perfection. Your decision to operate on a single VM and hardcoded configurations exemplifies the power of iterative experimentation; it keeps feedback loops short, reduces upfront complexity, and fosters a deep understanding of real user needs and system behavior.
This approach aligns well with the concept of “learn fast, iterate faster,” which is crucial in early-stage product development. As you noted, the key isn’t necessarily having the perfect architecture from day one but rather gaining actionable insights in a timeframe that allows for quick pivots and refinements.
One potential complement to this strategy might be establishing a clear plan to transition from these initial hacks to more scalable solutions as your platform matures—perhaps adding environment variables or configuration management tools when the benefits outweigh the costs. This phased approach ensures that scaling efforts are justified and informed by actual usage patterns.
Thanks again for sharing your methodology—it’s a valuable reminder that sometimes simplicity and speed can lead to more meaningful innovation than elaborate initial setups.