The 3-Month Rule: A Pragmatic Approach to Building Non-Scalable Solutions
In the world of startups, there’s a well-known piece of advice from Paul Graham: “Do things that don’t scale.” However, discussing how to translate this notion into coding practices is often overlooked. After eight months of developing my AI podcast platform, I’ve adopted a straightforward yet effective framework: I give every non-scalable solution a lifespan of three months. At the end of this period, each hack must either demonstrate its value and be properly integrated, or it will be discarded.
As engineers, we’re conditioned to think about scalable solutions from the outset. We envision intricate design patterns, microservices, and distributed systems that can handle vast user bases. This mindset is prevalent in larger companies. However, in a startup environment, focusing on scalability too early can lead to costly delays as you optimize for hypothetical users and problems that may never arise. My three-month rule encourages me to write simplified, straightforward, and even “imperfect” code that can be deployed quickly, allowing me to gain insights into what my users truly need.
Current Infrastructure Strategies: Why They Make Sense
1. Consolidating Everything on One Virtual Machine
My entire infrastructure—database, web server, background jobs, and Redis—runs on a single $40/month virtual machine. While this approach lacks redundancy and requires manual backups to my local machine, it has proven invaluable. In just two months, I’ve gained more understanding of my actual resource requirements than any extensive planning document could provide. I discovered that my platform, which is built on AI, experiences peak usage with only 4GB of RAM—far from the complex Kubernetes solution I almost opted for. Each time it crashes (which has happened twice), I gain genuine insights into what needs attention—often surprising me.
2. Simplified Hardcoded Configuration
Rather than utilizing configuration files or environment variables, I have hardcoded constants directly into the codebase, making adjustments as simple as redeploying. For example:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This approach may seem primitive, but its advantage lies in the ease of tracking changes. A simple search can uncover any configuration value, and all modifications are automatically captured in the git history. Instead of spending a week developing a configuration service, I
