Embracing the 3-Month Rule: A Technical Approach to Non-Scalable Solutions
In the world of startups, the prevailing wisdom from thought leaders like Paul Graham often stands out: “Do things that don’t scale.” However, translating that advice into actionable coding practices can be elusive. Over the past eight months of developing my AI podcast platform, I have crafted a straightforward yet effective framework that I call the 3-Month Rule. Essentially, any non-scalable solution I implement gets a trial period of three months. If it proves its worth, it will be built out properly; if not, it will be discarded.
The Dilemma of Scalability
As engineers, we are generally conditioned to prioritize scalable solutions from the outset. This includes everything from design patterns to intricate microservices and distributed systems—architectures designed to accommodate millions of users. However, in a startup context, pursuing scalability too early can often lead to unnecessary complexities and expenses, effectively resulting in procrastination for users that may not yet exist.
My 3-Month Rule encourages me to adopt simpler, more direct coding practices that deliver tangible results. By doing so, I gain invaluable insights into what my users actually need, allowing me to build solutions based on practical experiences rather than theoretical models.
Current Infrastructure Hacks: Learning Through Simplicity
1. Consolidated Resource Management
Currently, everything runs on a single virtual machine (VM) for an affordable $40/month. This includes the database, web server, and background jobs, all without redundancy. The absence of a complex setup has allowed me to determine my app’s actual resource requirements much more effectively than traditional capacity planning methods. I have discovered that my so-called “AI-heavy” platform saturates at a mere 4GB of RAM, which means that the elaborate Kubernetes setup I had considered would have been wasted on managing idle resources.
2. Hardcoded Configurations
My code includes direct constants for configurations—no dedicated configuration files or environment variables. Making any adjustments necessitates a simple redeployment. This approach has revealed its own benefits: finding any config value in seconds and tracking price changes easily in git history. In hindsight, planning for a configuration service would have consumed valuable time, whereas my solution has proven effective with minimal effort.
3. The Use of SQLite in Production
Running SQLite for a multi-user web application may raise eyebrows, but my database size is only 47MB, and it handles around
