Embracing the 3-Month Rule: A Pragmatic Approach to Developing Unscalable Solutions
In the ever-evolving landscape of software development, the conventional wisdom of “do things that don’t scale” is often bandied about, particularly by thought leaders like Paul Graham. However, the practical execution of this philosophy, particularly within the realm of coding, is rarely discussed.
Having dedicated the last eight months to creating my AI podcast platform, I have devised a pragmatic framework: every unscalable approach I implement is given a three-month trial period. At the conclusion of this period, each hack must either validate its worth and undergo proper development or be discarded.
Why Think Small?
As engineers, we’re often trained to prioritize scalability from the outset—embracing architectural paradigms such as microservices or distributed systems designed to accommodate millions of users. Yet, in the startup environment, this mindset can become a costly form of procrastination; we optimize for hypothetical future users and tackle problems that may never arise. My three-month rule compels me to prioritize simplicity, allowing me to write straightforward code that can be deployed quickly, thus revealing genuine user needs.
Current Infrastructure Hacks: Intelligent Choices for Growth
1. Consolidated Virtual Machine
Everything for my application—database, web server, background jobs, and caching—is hosted on a single $40/month virtual machine. While this setup offers no built-in redundancy and requires manual backups, the insights gained have proven invaluable. In just two months, I discovered my resource consumption peaks at a mere 4GB of RAM. The complex Kubernetes configuration I thought I needed? It would have merely managed empty containers. Each time the system crashes—twice so far—I gather critical information about real-world issues, often surprising me.
2. Hardcoded Configuration
Configuration values are hardcoded directly into the application, without the use of files or environment variables. This may seem backward, but it allows for rapid tracking and easy changes, with each adjustment captured in version history. Rather than investing a week to develop a sophisticated configuration service, I’ve made changes three times in three months, taking only 15 minutes for redeployment—an investment of time far less than the alternative.
3. SQLite for Production Use
Currently, my application runs on SQLite, which effectively powers a multi-user environment with a database size of only 47MB. Surprisingly, it manages 50 users simultaneously with ease. This experiment has taught me
