Embracing the 3-Month Rule: A Pragmatic Approach to Iterative Development
In the world of startups, where agility and adaptability are paramount, we often hear advice from industry veterans like Paul Graham: “Do things that don’t scale.” While this wisdom is widely acknowledged, discussions on how to effectively incorporate this principle into the technical realm are less common.
Over the last eight months, while developing my AI podcast platform, I devised a straightforward strategy: any solution or hack that doesn’t scale gets a maximum lifespan of three months. After this period, it either demonstrates its merit and earns a proper implementation, or it is discarded. This approach has helped me focus on delivering value rather than getting lost in the complexities of scalability too early in the process.
Rethinking Scalable Solutions
As engineers, we are often trained to prioritize scalable architectures, employing intricate design patterns, microservices, and distributed systems to prepare for high traffic and numerous users. However, this big-company mindset can lead to unnecessary over-engineering, particularly in a startup environment where scalability is frequently speculative.
My 3-month rule compels me to write straightforward, albeit imperfect, code that can be deployed quickly, allowing me to glean invaluable insights into user needs. Here are a few practical infrastructure hacks I’ve implemented that are proving to be surprisingly effective:
1. Consolidated Architecture on a Single VM
Currently, my entire stack — database, web server, background jobs, and caching — is hosted on a single, cost-effective VM. While this setup lacks redundancy and relies on manual backups, it has provided significant insights into my actual resource requirements. In just two months, I’ve learned that my platform peaks at 4GB of RAM, revealing that the expansive Kubernetes architecture I contemplated would have been a case of unnecessarily managing idle resources. Each crash incident, while inconvenient, provides me with real-time data on system weaknesses, which are often not what I had anticipated.
2. Simplicity in Configuration
My approach to configuration is refreshingly straightforward: constants are hardcoded throughout the codebase. Changing a value means redeploying, but this allows me to quickly search for and track changes. The time saved in setting up a configuration service has outweighed any potential downsides; the actual number of times I’ve altered configurations in three months has been negligible. This practical approach has dramatically reduced the engineering time typically devoted to configuration management.
3. Utilizing SQLite for Production Use
Sur
