The 3-Month Rule: A Practical Approach to Developing Non-Scalable Solutions
In the tech world, many are familiar with Paul Graham’s famous advice urging us to “do things that don’t scale.” However, the challenge often lies in applying this principle effectively, particularly when it comes to coding. After dedicating eight months to creating my AI podcast platform, I’ve discovered a straightforward framework that has proven invaluable: I grant each unscalable solution a lifespan of three months. At the end of this period, I assess whether it has demonstrated its value and is worth refining or if it should be phased out.
As engineers, we have a tendency to focus on building scalable solutions from the get-go. We become enamored with design patterns, microservices, and complex architectures that are capable of accommodating millions of users. While these methods are essential for larger companies, they can hinder the rapid iteration needed in a startup environment. Often, obsessing over scalability leads to wasted time and resources, as we optimize for potential users who may never appear and address problems that might not even exist.
Implementing my three-month rule has compelled me to write simpler, more straightforward code. This approach not only accelerates shipping but also provides clear insights into user needs.
My Current Infrastructure Hacks: Why They Work
1. All-in-One Virtual Machine
I’ve consolidated my entire stack—database, web server, background jobs, and Redis—onto a single $40/month virtual machine. While this means no redundancy and manual backups, it’s been incredibly enlightening. In just a couple of months, I gleaned more about my actual resource requirements than I would have through any detailed planning document. My “AI-driven” platform reaches peaks at only 4GB RAM. Had I deployed a complex Kubernetes system, I would have been managing idle containers instead.
Every time the system crashes—twice so far—I gain real data about failures. Notably, these failures have not come from where I initially anticipated.
2. Hardcoded Configurations
Instead of using separate config files or environment variables, I have opted for hardcoded constants throughout my code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this may seem inefficient, it allows me to quickly search for any configuration value across my entire codebase. I can track price
One Comment
This framework really highlights the power of intentional experimentation and prioritizing speed over perfection early on. The 3-month rule embodies a pragmatic mindset—by setting clear time boundaries for unscalable solutions, you create a natural feedback loop that informs whether to iterate further or pivot.
I especially appreciate your approach of using simple infrastructure like a single VM and hardcoded configs; these tactics reduce cognitive and operational overhead, freeing up resources to focus on learning and delivering value. It’s a refreshing reminder that genuine progress often comes from carefully contained experimentation rather than premature optimization.
Would love to hear how you balance the learnings from these quick-and-dirty solutions with planning for eventual scalability, especially as your platform grows. Thanks for sharing such actionable insights!