Embracing the 3-Month Rule: A Technical Framework for Non-Scalable Solutions

In the startup world, we often hear Paul Graham’s wisdom: “Do things that don’t scale.” However, there’s a noticeable gap in guidance on how to integrate this concept into the technical aspects of coding. As I embarked on my journey to build an AI podcast platform, I formulated a straightforward framework that I now call the “3-Month Rule.” This rule allows each non-scalable hack a lifespan of just three months. After that period, each hack must either demonstrate its value and be refined or be discarded altogether.

When you’re immersed in engineering, the primary focus is often on creating “scalable” solutions from the very beginning. With design patterns, microservices, and distributed systems dominating the conversation, it’s easy to forget the unique challenges faced by startups. In many cases, committing to scalable infrastructure early on amounts to expensive procrastination; you end up optimizing for users who aren’t yet there and addressing issues that may never surface. My 3-month rule compels me to stick with straightforward, albeit “messy,” code that delivers results and helps me glean vital insights about user needs.

Current Infrastructure Strategies That Work

1. Unified VM Infrastructure

Instead of spreading resources across multiple servers, I run my entire platform on a single $40/month virtual machine (VM) that houses my database, web server, background jobs, and even Redis. While this may seem risky with no redundancy and manual backups, the reality is that I’ve gained deeper insights into my resource requirements in two months than I ever could through hypothetical capacity-planning documentation. Surprisingly, my system peaks at just 4GB of RAM. The intricate Kubernetes setup I nearly embraced would have only complicated management without actually serving a purpose.

When the system crashes, as it has twice, I’m able to observe firsthand what goes wrong—often contrary to my expectations.

2. Hardcoded Configurations

My configuration strategy is to simply hardcode values directly within the codebase:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
No separate config files, no environment variables—just constants that are easy to track. Each deployment involves redeploying, but I can search my entire codebase instantaneously for any configuration value, and every adjustment is