Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech
In the startup world, the advice from entrepreneur and investor Paul Graham to “do things that don’t scale” resonates deeply. However, the challenge arises when trying to implement this wisdom in the realm of coding and development. As someone who has been diligently working on an AI podcast platform for the past eight months, I’ve devised a straightforward framework that has proven incredibly effective: every unscalable approach I adopt is given a trial period of three months. At the end of this time, I assess its worth—either it gets properly integrated, or it gets eliminated.
The Dilemma of Scalability
As engineers, we often strive to create scalable solutions right from the start. This encompasses sophisticated design patterns, microservices, and distributed systems thoughtfully crafted to handle millions of users. While such architectures are essential for larger organizations, they often represent an unrealistic focus for a startup still in its formative stages. Developing scalable code too early can stall progress and lead to costly procrastination.
The 3-month rule compels me to focus on simplicity. It encourages me to produce straightforward, if not entirely polished, code that can be delivered quickly while also revealing the true needs of users.
Current Infrastructure Hacks: Insights from My Experience
Here are a few key strategies I’ve implemented, underscoring that unconventional methods can indeed yield significant insights:
1. Unified VM Infrastructure
Currently, all aspects of my architecture—from database to background processing—are hosted on a singular $40/month virtual machine (VM). While this approach lacks redundancy and relies on manual backups, it has provided invaluable insights. Within just two months, I’ve gained a clearer understanding of my resource demands, discovering that my platform requires only 4GB of RAM at peak usage. The complex Kubernetes setup I nearly launched would have unnecessarily complicated matters.
2. Hardcoded Configurations
In my code, configuration values such as pricing and user limits are hardcoded rather than stored in separate config files or environment variables. While this may seem inefficient, it allows for rapid searches across my entire codebase and ensures that every configuration change is documented in version control. This approach has proven beneficial, as I’ve only needed to alter these values three times in three months—saving substantial engineering time.
3. Utilizing SQLite in a Production Setting
Despite potential skepticism, using SQLite has been remarkably effective for my multi-user web application. With a database size of
