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

In the world of startups, it’s common to hear the mantra “Do things that don’t scale,” famously advocated by Paul Graham. However, translating this advice into actionable steps within the realm of coding can often feel elusive. Over the past eight months, while building my AI podcast platform, I’ve developed a straightforward yet effective framework: every non-scalable hack is allotted a lifespan of three months. After this period, I evaluate its worth—if it proves beneficial, it earns a more robust solution; if not, it’s time to say goodbye.

Rethinking Scalability in Startups

As engineers, our training often focuses on devising scalable solutions from the get-go—think intricate design patterns, microservices, and distributed systems. This architecture is brilliant for accommodating massive user bases, but might not be ideal for a nascent startup. Sometimes, striving for early scalability is akin to delaying the inevitable while racking up expenses. By adhering to my 3-month guideline, I’m compelled to create straightforward and often imperfect code that might not conform to standard practices but can be launched quickly. This hands-on experience reveals what users genuinely require, surfacing insights that elaborate plans can obscure.

Key Infrastructure Hacks: Practical Examples

1. Unified Virtual Machine Deployment

My current setup operates on a single virtual machine (VM) that houses everything—from the database to background jobs. For just $40 a month, I have zero redundancy and perform manual backups to my local machine.

Here’s the brilliance in this approach: in two months, I’ve gained insights into my genuine resource requirements that no theoretical capacity planning document could elucidate. As it turns out, my platform only requires 4GB of RAM at peak times. The extensive Kubernetes architecture I was on the verge of implementing would have resulted in managing idle containers. Moreover, any crashes provide invaluable data regarding failures, often in areas I least expected.

2. Hardcoded Configuration Values

Configuration values are hardcoded throughout the codebase instead of stored in external files or environment variables. Here’s a peek:

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

While this approach lacks flexibility, it allows me to search for any configuration value