Embracing the 3-Month Rule: A Strategic Framework for Non-Scalable Solutions
In the tech world, we often hear the phrase from Paul Graham: “Do things that don’t scale.” While this concept is widely acknowledged, the practical implementation, particularly in the realm of coding, is rarely discussed.
After dedicating eight months to developing my AI podcast platform, I’ve formulated a straightforward yet effective approach: each non-scalable solution I employ is given a lifespan of three months. Within this timeframe, a strategy must either demonstrate its value and transition into a fully developed solution or be retired from use.
As engineers, we receive rigorous training to construct scalable solutions from the outset, focusing on design patterns, microservices, and robust architectures designed to support millions of users. Unfortunately, this mindset often aligns more with corporate development than with the dynamic environment of a startup. Here, pursuing scalability prematurely can lead to over-engineering and wasted resources—essentially procrastination for problems that may never arise.
By adopting the 3-month rule, I find myself compelled to produce straightforward, if imperfect, code that can quickly go live. This method allows me to gain valuable insights into what my users truly require.
Current Infrastructure Strategies: Why They’re Brilliant
1. Unified Virtual Machine Usage
All of my backend functions—including the database, web server, background jobs, and caching—run on a single $40/month virtual machine. While this may seem reckless due to the lack of redundancy and reliance on manual backups, it has been incredibly informative. Over the past two months, I’ve learned more about my resource requirements than any planning document could provide. The reality is that my “AI-heavy” platform only peaks at 4GB of RAM. Had I implemented a complex Kubernetes architecture, I would have been managing vainly empty containers. Each crash has yielded crucial insights about failure points that I never anticipated.
2. Hardcoded Configuration Values
I’ve opted for hardcoded constants rather than configuration files or environment variables. Modifying any settings involves a redeployment, but this approach brings its own advantages. I can easily search my entire codebase for configuration parameters with a simple grep command. This means all pricing changes are meticulously logged in git history, and updates are subject to my own code review processes. The time I save—15 minutes to redeploy versus an extensive 40 hours to build a configuration service—speaks for itself.
One Comment
This framework brilliantly highlights the value of rapid iteration and learning in startup environments. The 3-month rule acts as a powerful accountability tool, ensuring non-scalable solutions are given enough time to prove their worth without overcommitting prematurely. Your approach to using simple infrastructure—like a single VM and hardcoded configs—illustrates that in early stages, speed and direct feedback often outweigh the benefits of complex, scalable architectures.
It’s worth noting that this philosophy aligns well with the concept of “progress over perfection,” providing teams with flexibility to pivot while avoiding analysis paralysis. As your insights suggest, the critical factor isn’t just building solutions that work today but creating a disciplined process that constantly evaluates whether a solution should scale or be retired.
Would be interesting to hear how you plan to evolve these processes as your platform grows—do you anticipate switching to scalable solutions within a certain timeframe, or will you maintain this lean approach longer-term?