Embracing the 3-Month Rule: A Pragmatic Framework for Early-Stage Development
Innovation in the tech world is often accompanied by the mantra from renowned entrepreneur Paul Graham: “Do things that don’t scale.” Yet, implementing this advice—especially within the realm of software development—remains a topic that is frequently overlooked. After eight months of building my AI podcast platform, I’ve adopted a straightforward strategy: every unscalable workaround is given a three-month lifespan. At the end of this period, I evaluate whether it has proven its worth and deserves to be developed further, or if it should be discarded.
As engineers, we are often conditioned to prioritize scalable solutions right from the outset. We become adept at creating complex architectures involving microservices, distributed systems, and various design patterns that are all capable of handling vast amounts of users. However, this mindset is more aligned with larger companies rather than startups—where scalable solutions can sometimes become an expensive form of procrastination. In my experience, my three-month rule compels me to write straightforward, even “imperfect” code that enables me to gather crucial insights about user needs.
Current Hacks in My Infrastructure: Lessons Learned
1. Single Virtual Machine Setup
Currently, my entire architecture—web server, database, background processes, and caching—is hosted on a single virtual machine costing just $40 per month. While it may seem reckless due to the lack of redundancy and reliance on manual backups, this setup has provided invaluable insights into my actual resource consumption in a matter of two months. Instead of speculating, I learned that my platform peaks at a mere 4GB of RAM. The complex Kubernetes infrastructure I nearly opted for would have meant maintaining idle containers.
Moreover, each crash—occurring twice so far—has yielded real-time data on system failures, disproving many of my initial assumptions.
2. Hardcoded Configuration Values
My application contains hardcoded constants for configurations rather than relying on separate config files or environment variables. While this might appear to be an oversight, it allows me to quickly search for any configuration value across the entire codebase. Each update is recorded in Git history and effectively self-reviewed. Creating a configuration management system would be time-consuming, but I’ve only had to change these values three times in three months—resulting in just 15 minutes of redeployment versus the 40 hours a dedicated setup would demand.
3. Utilizing SQLite in Production
Surprisingly, my multi-user web
