Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the realm of technology and startups, one piece of advice often echoed is Paul Graham’s famous directive: “Do things that don’t scale.” However, the challenge lies in how to effectively implement this principle, especially when it comes to coding.
After eight months of developing my AI podcast platform, I’ve crafted a straightforward framework that I call the “3-Month Rule.” This approach dictates that any unscalable hack or workaround is permitted to exist for only three months. At the end of this period, its continued relevance is evaluated—either it delivers value and deserves a robust implementation, or it is discarded.
As engineers, we frequently gravitate towards building scalable solutions right from the outset. We immerse ourselves in design patterns, microservices, and distributed systems—concepts that cater to vast user bases. However, this mindset often aligns more with big corporations than with the realities of startups. In my experience, focusing on scalability too early is often a costly form of procrastination. It leads to optimizing for hypothetical users and crafting solutions for challenges that may never arise. The 3-Month Rule encourages me to write simpler, more direct code that can be launched quickly, providing real insight into what my users need.
Current Infrastructure Hacks: Ingenious Decisions
1. Consolidated on a Single Virtual Machine
I run my database, web server, background jobs, and caching all on a single $40/month virtual machine, without redundancy and with manual backups to my local device.
This might seem counterintuitive, but it has allowed me to assess my resource requirements accurately in just two months. My platform, designed for heavy AI usage, has only reached a peak of 4GB RAM usage. Instead of delving into the complexities of Kubernetes, which I nearly implemented, I’ve been able to understand my needs better without wasting resources on empty containers.
When the VM crashes—something that has happened twice so far—I gain valuable insights into actual failure points, which are often surprising.
2. Simplified Hardcoded Configurations
I utilize hardcoded constants across my application for pricing and user limits, without reliance on configuration files or environment variables. While this may seem outdated, it boasts an unexpected advantage: I can swiftly search through my entire codebase for configuration values. Each update is meticulously tracked through Git history, ensuring a streamlined process with minimal overhead.
Creating a configuration
