The 3-Month Rule: An Efficient Approach to Testing Unscalable Solutions in Development
In the startup world, you may have heard the popular advice from Paul Graham: “Do things that don’t scale.” However, the challenge often lies in figuring out how to effectively implement this principle in the realm of coding.
After dedicating eight months to the development of my AI podcast platform, I’ve established a straightforward framework: every unscalable workaround has a three-month lifespan. At the end of this period, each hack must either demonstrate its value and evolve into a robust solution or be discarded.
The Reality of startup Development
As engineers, we are typically trained to design scalable solutions from the outset. We delve into the intricacies of design patterns, microservices, and distributed systems, creating architectures capable of accommodating millions of users. However, this train of thought is more aligned with the big company mentality. In a startup setting, aiming for scalable code can often lead to costly procrastination. We focus on future users who don’t exist yet, tackling issues that may never arise.
My three-month rule encourages me to create direct and imperfect code that is deployable, allowing me to gain insights into what users genuinely require.
Practical Infrastructure Choices: Why They Make Sense
1. Consolidated Resources
I run my entire platform—database, web server, background jobs, and caching—on a single $40/month virtual machine (VM). While this setup offers no redundancy and requires manual backups to my local storage, it has provided invaluable insights into my actual resource needs. Within two months, I learned that my “AI-heavy” platform only peaks at 4GB of RAM, revealing that my planned complex Kubernetes setup would have merely managed non-existent containers. Additionally, when the server crashes—which has happened a couple of times—I receive concrete data on the actual failures, which often differ from my initial assumptions.
2. Hardcoded Constants
My code features hardcoded configuration values like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no configuration files or environment variables—just constants spread throughout the codebase. While changing a value necessitates redeployment, this method offers a hidden advantage: I can quickly search my entire codebase for any configuration value. In just three months, I’ve modified these
