Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the world of entrepreneurship, the well-known advice from Paul Graham resonates: “Do things that don’t scale.” Yet, when it comes to software development, especially coding, few provide guidance on how to effectively implement this concept. After dedicating eight months to the development of an AI podcast platform, I have devised a straightforward framework: every unscalable solution has a lifespan of three months. Following this period, it either demonstrates its value and warrants further investment, or it is discarded.
As engineers, our training often leads us to pursue scalable solutions from the outset. We are trained in design patterns, microservices, and distributed systems, envisioning architectures capable of supporting millions of users. However, this line of thinking can be limiting, particularly for startups. Scalable code can often become a form of costly procrastination, preemptively addressing user needs that may never materialize. My three-month rule encourages me to create straightforward, even “bad,” code that can be delivered quickly, thus helping me gain insights into actual user requirements.
Current Infrastructure Strategies and Their Strategic Implications
1. Consolidated Operations on a Single VM
My entire stack—database, web server, background jobs, and caching—is running on a single $40/month virtual machine without any redundancy. While this may sound reckless, it has provided invaluable insights. In just two months, I have gained a clearer understanding of my resource demands. For instance, my platform’s maximum RAM usage only reaches 4GB, which means an elaborate Kubernetes setup would have been unnecessarily managing idle resources. Each time the system crashes—I’ve experienced this twice—I receive real data about what truly fails, which is often surprising.
2. Hardcoded Configurations Throughout the Codebase
In my code, configurations are hardcoded as constants—no separate config files or environment variables. Adjusting any value means redeploying the application. The benefit of this approach is clarity; I can quickly search my codebase for any configuration and track changes in Git history. Developing a configuration service would consume a week of resources, yet I’ve made only three parameter changes in three months. This translates to a mere 15 minutes of redeployment instead of 40 hours of development.
3. Utilizing SQLite in a Production Environment
My choice to run SQLite for a multi-user web application may seem unconventional, but it has proven effective
One Comment
Thank you for sharing your practical approach to embracing the 3-month rule—it’s a refreshingly honest perspective that highlights the value of rapid experimentation over premature optimization. I particularly appreciate how you’ve identified tangible ways to gain insights early, such as running everything on a single VM and hardcoding configurations for quick iteration.
This reminds me of the importance of “assuming failure” as a learning tool—by intentionally keeping things simple and sometimes “bad,” you reveal actual bottlenecks and user needs without overinvesting in questionable scalability upfront. It’s a strategic mindset that can lead to smarter, more targeted solutions down the line.
One suggestion might be to periodically review these “unscalable” solutions after the three months, documenting what worked, what didn’t, and what needs to scale. This way, you maintain the agility of your experimentation phase while gradually transitioning to more scalable architectures only when justified by real growth and demand.
Overall, I think your framework offers a valuable roadmap for startups and engineers alike—prioritize speed and learning over perfection, and let real-world data guide the evolution of your infrastructure.