Embracing the 3-Month Rule: A Strategic Approach to Unscalable Coding

In the tech entrepreneurial landscape, a well-known principle from Paul Graham encourages developers to “do things that don’t scale.” However, discussions on how to pragmatically apply this philosophy in coding practices are often lacking.

After dedicating eight months to creating my AI podcast platform, I’ve devised a straightforward framework: any unscalable approach is given a trial period of three months. At the end of this period, each method must either prove its worth and be adapted for growth, or it will be phased out.

As engineers, we’re frequently indoctrinated to prioritize “scalability” from the get-go, often gravitating towards complex architecture like microservices and distributed systems designed for vast user bases. This mindset is more suited to established corporations than startups. In a startup setting, focusing on scalability too soon can amount to expensive procrastination, addressing needs that don’t yet exist and solving problems that may never arise. By following my three-month rule, I am compelled to create straightforward, albeit imperfect, solutions that enable me to directly understand user requirements.

Current Infrastructure Strategies and Their Intelligence:

1. Single VM for All Services

I host my entire stack—database, web server, background jobs, and caching—on one $40/month virtual machine. While this setup offers zero redundancy and relies on manual backups, the insights gained are invaluable. Over the past two months, I’ve identified my actual resource needs far more effectively than any theoretical capacity plan could provide. Surprisingly, my platform’s peak demand reaches only 4GB RAM. The intricate Kubernetes system I nearly implemented would have meant managing idle containers rather than addressing real challenges.

When the system crashes—which has happened a couple of times—I gain critical information about actual failures, revealing that the breakdown points are seldom what I anticipated.

2. Hardcoded Configurations

My approach eliminates external configuration files or environment variables, instead opting for hardcoded constants like:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

This choice may seem counterintuitive, as it requires redeploying for changes. However, this conventional tactic enables rapid searches across my codebase for any configuration value, making tracking price changes easy via Git history. I have altered these constants only three times over the last three months,