Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Software Development
In the world of startups and software development, the importance of creating scalable solutions is often emphasized. Paul Graham’s famous advice, “Do things that don’t scale,” resonates with many entrepreneurs and developers. However, the implementation of this principle within technical frameworks isn’t widely discussed. Having spent eight months building my AI podcast platform, I’ve discovered an effective strategy: every non-scalable hack I implement has a shelf life of three months. After this period, I assess its value—either it gets the investment it needs to evolve or it is discarded.
As engineers, we’re conditioned to prioritize scalable solutions from the beginning. We admire sophisticated architecture with design patterns, microservices, and distributed systems that cater to millions of users. However, this mindset can be counterproductive for startups. Focusing too heavily on scalability often leads to unnecessary complexity and delays, optimizing for hypothetical users rather than addressing current needs. My three-month rule encourages me to deploy straightforward, less-than-perfect code that provides real insights into user behavior.
My Ingenious Infrastructure Hacks
1. Consolidation on a Single VM
Currently, I operate my entire platform—including the database, web server, background jobs, and caching—on one $40 per month virtual machine. There’s no redundancy, and I manually back up the data to my local machine. This might sound reckless, but it’s provided invaluable insights into my resource utilization. In merely two months, I’ve learned my platform’s peak demand is just 4GB of RAM, negating the need for the complex Kubernetes setup I initially considered. Notably, when the system does crash—which has happened twice—I gain crucial data about what went wrong, often revealing surprises.
2. Hardcoded Configuration
I use hardcoded constants for configuration, rather than relying on environment variables or config files:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This may seem inefficient; however, it allows me to quickly search through my codebase and track historical changes via Git. Over three months, I’ve only modified a few values, making the trade-off between minor redeployment time and extensive engineering time worthwhile.
3. Using SQLite in Production
Yes, I chose SQLite for my multi-user
