Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Code
In the entrepreneurial world, one adage often resonates: “Do things that don’t scale,” as famously advised by Paul Graham. However, translating this philosophy into practical implementation — particularly in software development — is seldom discussed. After dedicating eight months to the development of my AI podcast platform, I devised a straightforward framework: every non-scalable approach is given a lifespan of three months. At the end of this period, it must justify its continued existence or be phased out.
As engineers, we are instinctively taught to create solutions that are scalable from the outset. This often leads us to focus on intricate design patterns, microservices, and distributed systems — the kind of complex architecture that caters to millions of users. While this works wonders for established companies, in the startup realm, focusing solely on scalability can frequently amount to costly procrastination.
My three-month framework encourages me to embrace straightforward, even “imperfect,” coding practices that allow me to deliver functional products. This strategy ultimately reveals the genuine needs and behaviors of my users.
Current Infrastructure Strategies: Smart Solutions from Simplicity
-
Single Virtual Machine for Everything
Utilizing a single $40/month virtual machine to manage my database, web server, background processes, and Redis may seem imprudent. However, this approach has granted me invaluable insights into my resource requirements. Within just two months, I discovered that my platform, which I anticipated to be resource-heavy, only peaks at 4GB of RAM. This experience has shown me that deploying elaborate systems prematurely can often lead to managing empty resources. -
Hardcoded Configuration
Instead of using environment variables or configuration files, I practice hardcoding key values directly into the application. For instance:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This approach allows me to make swift changes by simply redeploying, with the benefit of tracking all alterations in my version control system. The time saved here is significant; while creating a dedicated configuration service might take a week, my real-world adjustments over three months have only taken about 15 minutes. -
SQLite as my Active Database
My choice to run SQLite for a multi-user application may raise eyebrows, but
One Comment
This is a refreshingly pragmatic take on the “doing things that don’t scale” philosophy. I appreciate your emphasis on rapid experimentation and learning—especially how limiting upfront effort to set up complex, scalable systems allows for real-world insights to shape subsequent development stages. The three-month rule provides a clear, time-bound framework that encourages immediate functionality and user feedback before committing to more elaborate infrastructure.
Your examples—using a single VM, hardcoded configs, and SQLite—highlight how simplicity can accelerate iteration and uncover actual user needs. I’d add that this approach aligns well with lean startup principles, where validated learning takes precedence over premature optimization. As your platform matures, shifting to more scalable architectures can then be guided by concrete data, reducing waste and ensuring resources are allocated effectively.
Overall, this strategy fosters agility and encourages entrepreneurs and developers to focus on solving real problems first, rather than getting bogged down in scalability discussions prematurely. Thanks for sharing such practical insights!