The Three-Month Rule: A Practical Approach to Unscalable Coding
When it comes to startup culture, one piece of advice rings true: “Do things that don’t scale.” Yet, despite its prevalence in discussions, the practical implementation of this mantra in coding remains obscured. As the creator of an AI podcast platform over the past eight months, I have devised a straightforward framework: any unscalable solution gets a lifespan of three months. If it proves effective, it will be developed further; if not, it will be discarded.
As engineers, we often find ourselves wedded to the concept of building scalable systems from the outset. The allure of design patterns, microservices, and robust architectures meant to support millions of users is strong but may be more relevant to larger enterprises than to startups. In the world of startups, focusing on scalability can lead to wasting time on optimization for non-existent users while ignoring immediate needs. My three-month rule compels me to produce simpler and more direct code that allows for actual delivery and real-time learning about user requirements.
Key Infrastructure Hacks That Are Surprisingly Effective
1. Condensing Everything into a Single Virtual Machine
Imagine running your database, web server, background jobs, and caching all from one $40-a-month virtual machine. While it may seem risky given the lack of redundancy and the manual backup process, this approach provided invaluable insights about resource consumption. Within just two months, I discovered my “AI-driven” platform peaks at only 4GB of RAM. What could have spiraled into an elaborate Kubernetes configurations ended up being an exercise in managing empty containers.
When my server has faced downtime (twice so far), I’ve learned firsthand what causes issues, which has often defied my expectations.
2. Embracing Hardcoded Configuration
With configuration values like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 hardcoded throughout my files, I have forgone the complexity of configuration files or environment variables. This may seem inefficient, but it ensures that any changes are quickly accessible via a simple grep across my codebase. Each modification is documented in git, retaining every historical change. Rather than spending a week creating a configuration service, I’ve only needed to redeploy my application three times in three months—a minute’s worth of effort instead of a potential 40-hour project.
3. Utilizing SQLite for Production
Yes, I am using SQLite for a multi-user
