Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Software Development
In the entrepreneurial realm, a well-known piece of wisdom from entrepreneur and investor Paul Graham advises founders to “do things that don’t scale.” Yet, there’s a notable lack of guidance on how to effectively apply this principle, particularly within the context of software engineering.
After eight months of developing my AI podcast platform, I’ve crafted a straightforward yet effective framework: every unscalable approach gets a dedicated three-month trial period. Within this time frame, it must either demonstrate its worth to warrant a full-scale implementation or be discarded.
As engineers, we often operate under the assumption that scalability should be our primary goal from the outset. We immerse ourselves in the details of design patterns, microservices, and distributed systems—all essential for accommodating vast numbers of users. However, this mindset aligns more closely with that of large corporations rather than startups.
In a startup environment, focusing excessively on scalability can lead to costly delays in execution. It can encourage us to optimize for an imagined user base while ignoring the immediate needs of our current actual users. My three-month rule compels me to craft straightforward, sometimes suboptimal, solutions that can be deployed quickly, allowing me to gauge user feedback and needs effectively.
My Current Infrastructure Techniques and Their Practical Insights:
1. Consolidating Everything on a Single VM
I host my database, web server, background jobs, and Redis on a single $40/month virtual machine. There’s no redundancy, and I perform manual backups to my local device.
Why is this a sound strategy? This approach has provided me with valuable insights regarding my actual resource requirements within just two months—insights that traditional capacity planning could never have revealed. For instance, my AI-driven platform peaked at only 4GB of RAM usage. The intricate Kubernetes setup I previously considered would have been managing more containers than necessary.
When the system crashes (which has happened twice), I gain concrete data about what fails—often surprising discoveries that challenge my expectations.
2. Hardcoded Configurations Throughout the Codebase
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
I’ve opted to use hardcoded constants scattered throughout my code rather than utilizing configuration files or environment variables. Making changes requires a redeployment.
The advantage? I can quickly search
