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
One Comment
Thank you for sharing this insightful approach. The 3-Month Rule resonates strongly with the startup mentality of rapid experimentation and learning. By imposing a clear time limit on hacks and workarounds, you effectively balance the need for immediate progress with thoughtful evaluation. I appreciate how this methodology encourages avoiding the trap of over-engineering early on, which can indeed hinder agility.
Your example of consolidating everything into a single VM and using hardcoded configs highlights a pragmatic attitude—prioritizing real-world validation over premature optimization. It’s a reminder that sometimes, simple solutions can provide the clearest insights into your actual needs.
Moving forward, it would be interesting to consider how to integrate this rule with ongoing iteration—perhaps setting periodic review points beyond the initial three months for features that prove their value. Overall, your framework offers a practical roadmap for early-stage developers to stay focused and adaptable.