Embracing the 3-Month Rule: A Framework for Learning through Unscalable Solutions
In the entrepreneurial realm, Paul Graham’s notion of “doing things that don’t scale” resonates with many. But how does this concept translate into practical coding strategies? After eight months of developing my AI podcast platform, I’ve devised a straightforward framework: each unscalable solution has a lifespan of three months. At the end of this period, we assess its value—if it’s beneficial, we refine it; if not, it’s discarded.
As engineers, we often start our projects with scalability in mind. We lean toward complex design patterns, microservices, and distributed systems. While these are admirable for handling vast user bases, they often reflect the mindset of larger organizations. For startups, however, investing time in scalable solutions can lead to costly delays. Often, we find ourselves optimizing for a user base that might never materialize or tackling issues that are not yet relevant. My 3-month rule encourages me to implement straightforward, sometimes “imperfect,” code that is deployable and helps me uncover user needs more effectively.
Current Infrastructure Hacks Teaching Me Valuable Lessons
1. Single VM Architecture
I currently run everything—a database, web server, background jobs, and Redis—on a single virtual machine costing just $40 a month. Yes, there’s no redundancy, and all backups are done manually. Yet, this setup has provided invaluable insights into my actual resource requirements in just two months. I’ve found that my “AI-heavy” platform peaks at just 4GB of RAM. The extensive Kubernetes architecture I was considering would have been wasted effort managing idle containers. When crashes occur (and they have, twice), I gather real data that reveals the unexpected weaknesses in my application.
2. Hardcoded Configuration
I’m managing configuration with hardcoded constants scattered throughout my codebase—no separate config files or environment variables. This atypical approach, albeit seemingly primitive, offers significant advantages. I can quickly search my entire code for any configuration value, with every price change logged in version control. In the three months since I’ve implemented this, I’ve only changed configurations three times, saving countless hours that would have been spent creating a dedicated configuration service.
3. Using SQLite in a Multi-user Environment
Surprisingly, I’m utilizing SQLite as the backbone for my multi-user application, with the entire database sitting at a mere 47MB and successfully managing 50 concurrent users
