Embracing the 3-Month Rule: A Practical Approach to Unscalable Engineering

In the tech world, Paul Graham’s concept of doing things that don’t scale is well-known, yet the implementation of this principle in coding practices is often overlooked. After eight months of developing my AI podcast platform, I’ve established a straightforward framework that I call the “3-Month Rule.” This guideline dictates that every unscalable hack I employ has a lifespan of three months. At the end of this period, each solution is evaluated for its effectiveness: it either gets refined into a robust system or is discarded.

As engineers, we are often encouraged to create scalable solutions from the outset, with a strong emphasis on design patterns and architectures capable of supporting millions of users. However, this approach typically aligns more with large organizations than with startups, where pursuing scalable code often results in unnecessary delays. By committing to my 3-month rule, I focus on writing straightforward, albeit less-than-ideal code that is functional and helps me gather valuable insights into user needs.

Current Infrastructure Workarounds: Why They Make Sense

1. Consolidated Infrastructure on a Single VM

I’m running my entire stack—database, web server, background jobs, and caching—on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, it’s offered me crucial insights into my resource usage. Within two months, I learned that my platform usually operates with just 4GB of RAM, which likely would have been lost amidst a complex Kubernetes architecture. Each crash has provided real data about system vulnerabilities—information I would have otherwise misjudged.

2. Directly Hardcoded Configurations

Throughout my codebase, configurations like pricing tiers and user limits are hardcoded as constants. Although this means any change requires redeployment, it allows for swift searches across files and simplifies tracking in version control. Over three months, I made precisely three updates—spending a mere 15 minutes redeploying instead of investing countless hours to build a separate configuration service.

3. Using SQLite for Production

Yes, my multi-user web application operates on SQLite, with a tiny database size of just 47MB that efficiently supports 50 concurrent users. This decision stemmed from identifying that 95% of my access patterns were read operations, which SQLite handles adeptly. Had I opted for a more complex system like Postgres, I could have wasted energy on