Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions

In the world of startups and innovation, Paul Graham’s timeless advice to “do things that don’t scale” resonates powerfully. However, when it comes to actual implementation, especially in coding, the conversation often falls short. Over the past eight months while developing my AI podcast platform, I’ve adopted a straightforward framework: any unscalable solution gets a trial period of three months. After that, it must either prove its worth to transform into a more robust system or be discarded.

The Dilemma of Scalability

As engineers, we are often conditioned to think of scalability from the outset. We aspire to design systems that can cater to millions of users, employing complex architectures like microservices and distributed systems. Such grand designs are typically associated with large corporations, but in a startup environment, this mentality can lead to costly delays. It turns out that focusing on scalability too soon can hinder our responsiveness to real-time feedback from users.

My three-month rule obliges me to prioritize simplicity over perfection. Instead of creating intricate code for hypothetical future users, I’m experimenting with direct, minimalistic solutions that can actually help me understand user needs.

Lessons Learned Through My Current Infrastructure

1. Consolidation: One VM for All

I operate everything—database, web server, background jobs, Redis—all on a single $40/month virtual machine (VM). There’s no redundancy, and backups are done manually to my local system.

Why is this an effective strategy? It has provided invaluable insights into my true resource requirements within just two months. My platform, which I initially expected to demand a lot of resources, typically peaks at just 4GB of RAM. The elaborate Kubernetes setup I considered would have merely managed idle containers.

During the two times the system crashed, I gleaned crucial information about actual failure points, which were quite different from my initial assumptions.

2. Simplified Hardcoding

Instead of using configuration files or environment variables, I have hardcoded vital parameters like:

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

While it may sound primitive, this method allows for quick searches through my codebase. Any configuration change is easily tracked in Git history, and since I’ve only modified these values thrice