Embracing the 3-Month Rule: My Non-Scalable Approach to Software Development
In the world of startups, where uncertainty reigns and resources are often limited, the advice from Paul Graham, “Do things that don’t scale,” takes on a profound significance. However, when you’re knee-deep in coding, how do you put this principle into action? After eight months of building my AI podcast platform, I’ve developed a straightforward framework that I call the 3-Month Rule: every non-scalable solution is given a trial period of three months. If it proves its worth, we build it properly; if not, it gets retired.
As engineers, we’re conditioned to create scalable solutions from the outset. We immerse ourselves in design patterns, microservices, and distributed systems, all crafted to accommodate potential millions of users. Yet, that mindset often belongs to larger organizations. In a startup environment, obsessing over scalability can lead to costly procrastination. It encourages us to optimize for hypothetical users and preemptively address problems that may never arise.
The 3-Month Rule empowers me to write straightforward, albeit imperfect, code that yields results and provides valuable insights into user needs. Below are some current infrastructure hacks I’ve implemented, demonstrating that simplicity can lead to smart decisions.
Current Infrastructure Hacks: A Smart Approach
1. One Virtual Machine for Everything
I’ve centralized my database, web server, background jobs, and Redis on a single $40/month virtual machine, sacrificing redundancy and employing manual backups to my local machine.
This approach, far from being reckless, has taught me more about my resource usage in two months than any extensive capacity planning document could. I learned that my AI-intensive platform only peaks at 4GB of RAM—meaning the complex Kubernetes setup I nearly built would have wasted resources managing empty containers. When downtime occurs (which has happened twice), I gather real data on the root causes, uncovering issues I never anticipated.
2. Simplistic Hardcoded Configuration
My configuration is simple: constants like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 litter the codebase, eliminating the need for configuration files or environment variables.
The beauty of this setup? I can swiftly search my entire codebase for any value, tracking price changes through git history. In the three months since I started, I’ve altered these values just three times, saving countless hours of engineering work for a minimal redeployment
