Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Coding
In the startup landscape, the mantra “Do things that don’t scale,” attributed to Paul Graham, is often echoed but rarely explained in a coding context. Over the past eight months of developing my AI podcast platform, I have created a straightforward framework to implement this philosophy: every unscalable hack I devise is given a three-month lifespan. After this period, it either proves its worth and is transformed into a well-structured solution, or it is discarded.
As engineers, we tend to focus on creating scalable solutions from the outset, investing in advanced architectures like microservices, distributed systems, and well-designed design patterns that can accommodate millions of users. This level of thinking is certainly suited for larger enterprises but can be detrimental in a startup environment. Here, striving for immediate scalability often leads to delays and unnecessary complexity, as it optimizes for hypothetical future users and problems.
My three-month rule has been pivotal in allowing me to write straightforward, even rudimentary, code that can be deployed quickly. This approach provides invaluable insights into user needs and behavior, emphasizing the learning process over perfection.
Current Infrastructure Hacks: Smart Simplifications
1. Consolidated Hosting on a Single VM
I currently operate my entire platform—database, web server, background jobs, and caching—on a single virtual machine costing $40 a month. By eliminating redundancy and using manual backups, I’ve gained insights into my resource requirements that would have eluded me through traditional capacity planning. In just two months, I realized my platform, perceived as resource-intensive, only uses 4GB of RAM. My initial inclination to set up a complex Kubernetes architecture would have resulted in unnecessary resource management.
Crashes (which have occurred a couple of times) provide real-time data that reveals unforeseen weaknesses in my architecture, igniting my understanding of where improvements are truly needed.
2. Hardcoded Configuration for Simplicity
Instead of sprawling configuration files or environment variables, I utilize hardcoded constants directly within my code. Changing values necessitates a redeployment process, but this streamlined method enables me to quickly search and track configurations across my entire codebase. The time saved is invaluable; minor adjustments may take 15 minutes compared to the estimated 40 hours that creating a dedicated configuration management system would require.
3. Utilizing SQLite in Production
Yes, I’m employing SQLite for my web application, and it has performed admirably
