Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the world of tech, the phrase “do things that don’t scale” frequently trips off the tongue, particularly those of Paul Graham. While the sentiment is widely acknowledged, the practical implementation, especially in coding environments, is often overlooked.
After dedicating eight months to developing my AI podcast platform, I’ve formulated a straightforward strategy that I call the 3-Month Rule. This framework stipulates that any non-scalable hack is given a lifespan of three months. At the end of this time, it must either demonstrate its value and transform into a well-constructed feature, or it will be discarded.
As engineers, we are conditioned to pursue scalable solutions right from the outset. We tend to get enamored by design patterns, microservices, and distributed systems—architectures capable of supporting millions of users. However, this is a mindset best suited for larger organizations.
In the startup realm, focusing on scalability too early can lead to unnecessary complexity and serve as a form of procrastination, creating solutions for users that do not yet exist. My 3-Month Rule compels me to implement straightforward, albeit less-than-ideal solutions, allowing me to learn about the actual demands and preferences of my users.
My Current Unscalable Solutions: Strategic Insights
1. Single-VM Infrastructure
I operate all essential functions—database, web server, background jobs, and Redis—on a single virtual machine for just $40 a month. Although this setup lacks redundancy and relies on manual backups, it has provided invaluable insights.
In just two months, I’ve gained a clearer understanding of my resource requirements than any planning document could offer. It turns out my AI-centric platform only requires about 4GB of RAM during peak times. The complex Kubernetes architecture I almost adopted would have been an exercise in managing theoretical resources.
When my setup crashes, I’ve collected real data on the failures, which often surprise me.
2. Hardcoded Configuration Values
Instead of utilizing configuration files or environment variables, my constants are hardcoded and scattered throughout the code. This approach allows for swift searches across the codebase. With each price change tracked in git history, I can make modifications efficiently, spending 15 minutes redeploying rather than devoting hours to build a configuration service that may not be necessary.
3. Utilizing SQLite for Production
My entire database,
