The 3-Month Rule: A Practical Approach to Unconventional Coding Strategies
In the realm of startups, conventional wisdom often holds that one should focus on scalable solutions from the get-go. But what if the secret to creating a successful product lies in embracing the opposite approach? This is the concept behind the famous advice from Paul Graham to “do things that don’t scale.” While many agree with this perspective, few delve into how it can be effectively implemented in the world of software development.
After eight months of building my AI podcast platform, I have devised a straightforward yet impactful framework known as the “3-Month Rule.” Under this system, any unscalable hack is given a lifespan of three months to either prove its worth and transition into a more robust solution or be discarded altogether.
Rethinking Scalability in Startups
As engineers, we often fall into the trap of meticulously crafting scalable solutions with complex architectures—think microservices and distributed systems—designed for handling millions of users. However, this mindset can lead to excessive preparation and wasted resources in the early stages of a startup, where the focus should be on validating ideas with real users.
My 3-month rule encourages a more pragmatic approach: write simple, even “messy” code that gets released and provides genuine insights into user needs and behaviors.
Current Infrastructure Hacks and Their Value
1. Consolidation on a Single Virtual Machine (VM)
I run my entire stack—including the database, web server, background jobs, and cache—on a single $40 per month VM. While this setup lacks redundancy and requires manual backups, it has provided invaluable insights into my resource needs.
After just two months, I discovered that my so-called “AI-heavy” platform requires a maximum of 4GB of RAM. Had I pursued an elaborate Kubernetes architecture, I would have been preemptively managing a system that was not yet necessary.
2. Using Hardcoded Configuration
Instead of maintaining complex configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. While this choice means every adjustment necessitates a redeployment, it enables me to quickly search for configuration values and maintain a historical record in version control.
In the past three months, I have adjusted configuration settings only three times, which translates to a mere 15 minutes for redeployment—far less than the hours that would have gone into creating a configuration management service.
