The 3-Month Rule: A Practical Approach to Developing Non-Scalable Solutions

In the tech world, many are familiar with Paul Graham’s famous advice urging us to “do things that don’t scale.” However, the challenge often lies in applying this principle effectively, particularly when it comes to coding. After dedicating eight months to creating my AI podcast platform, I’ve discovered a straightforward framework that has proven invaluable: I grant each unscalable solution a lifespan of three months. At the end of this period, I assess whether it has demonstrated its value and is worth refining or if it should be phased out.

As engineers, we have a tendency to focus on building scalable solutions from the get-go. We become enamored with design patterns, microservices, and complex architectures that are capable of accommodating millions of users. While these methods are essential for larger companies, they can hinder the rapid iteration needed in a startup environment. Often, obsessing over scalability leads to wasted time and resources, as we optimize for potential users who may never appear and address problems that might not even exist.

Implementing my three-month rule has compelled me to write simpler, more straightforward code. This approach not only accelerates shipping but also provides clear insights into user needs.

My Current Infrastructure Hacks: Why They Work

1. All-in-One Virtual Machine

I’ve consolidated my entire stack—database, web server, background jobs, and Redis—onto a single $40/month virtual machine. While this means no redundancy and manual backups, it’s been incredibly enlightening. In just a couple of months, I gleaned more about my actual resource requirements than I would have through any detailed planning document. My “AI-driven” platform reaches peaks at only 4GB RAM. Had I deployed a complex Kubernetes system, I would have been managing idle containers instead.

Every time the system crashes—twice so far—I gain real data about failures. Notably, these failures have not come from where I initially anticipated.

2. Hardcoded Configurations

Instead of using separate config files or environment variables, I have opted for hardcoded constants throughout my code:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this may seem inefficient, it allows me to quickly search for any configuration value across my entire codebase. I can track price