Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Coding for Startups
In the entrepreneurial world, there’s a well-known maxim from Paul Graham: “Do things that don’t scale.” However, there seems to be a lack of discussion regarding its practical application in the realm of coding. After dedicating eight months to developing my AI podcast platform, I have devised a straightforward and effective framework: every unscalable approach is granted a life span of three months. At the end of this period, it either demonstrates its worth and is transformed into a robust feature or it is discarded.
As software engineers, we are often conditioned to seek out scalable solutions from the outset. We dive into design patterns, microservices, and distributed systems—these intricate architectures designed to support millions of users. Yet, this line of thinking often doesn’t align with the realities of startup life.
At a young startup, investing time in scalability can often mean delaying crucial progress. Instead of addressing immediate needs, we’re sidestepping challenges to prepare for hypothetical users who may never arrive. My three-month rule has encouraged me to produce straightforward, albeit imperfect, code that allows me to ship features quickly and gain valuable insights into user needs.
Current Infrastructure Strategies: Why They Make Sense
- Unified Virtual Machine Setup
Currently, all my operations run on a single $40/month virtual machine—including the database, web server, and background jobs. While this might seem risky due to the absence of redundancy and reliance on manual backups, it has afforded me invaluable insights. Within just two months, I’ve come to understand my actual resource requirements far better than any theoretical capacity planning could. It turns out my resource-heavy platform peaks at only 4GB of RAM. The advanced Kubernetes architecture I had initially planned would have been wasted managing unutilized containers. When the system crashes (which it has done a couple of times), I get firsthand data about what really fails—often not what I originally anticipated.
- Hardcoded Configurations for Simplicity
Rather than using configuration files or environment variables, I keep constants like pricing and user limits directly in the code. While some might argue that this approach lacks flexibility, I’ve found it to be a “hidden superpower.” I can swiftly search my codebase for any configuration value, with every change neatly logged in my git history. In just three months, I’ve altered these values three times, making the 15 minutes of redeployment
