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

When it comes to startup advice, Paul Graham’s famous phrase, “Do things that don’t scale” typically generates much discussion. However, the practical implementation of this advice, especially in the realm of coding, often goes unaddressed. After eight months of developing my AI podcast platform, I’ve devised a straightforward yet effective framework: every unscalable workaround is given a lifespan of three months. At the end of this period, if the hack has demonstrated enough value, it will be properly integrated; otherwise, it will be discarded.

As engineers, our training often emphasizes the importance of creating scalable solutions from the outset. Concepts like design patterns, microservices, and distributed systems enable applications to serve millions. However, this mindset often suits larger corporations rather than nimble startups.

In reality, focusing on scalability too early can lead to unnecessary complexity and hinder progress. Many startups face the challenge of optimizing for a user base that may not even exist yet. By adhering to my three-month rule, I compel myself to produce straightforward and even “imperfect” code that is actually deployed, allowing me to understand firsthand what users truly need.

My Key Infrastructure Hacks and Their Unexpected Brilliance

1. Unified Operations on a Single VM

I run everything—database, web server, background jobs, and Redis—on a single $40/month virtual machine. This setup lacks redundancy, and I manage manual backups on my personal machine.

Why is this a strategic advantage? In just two months, I’ve gained insights into my actual resource needs that no volume of capacity planning documents could provide. My “AI-heavy” platform operates seamlessly with just 4GB of RAM. The sophisticated Kubernetes architecture I initially considered would have merely resulted in managing idle containers.

Every instance of downtime has presented valuable data on failures, consistently revealing unexpected points of failure.

2. Hardcoded Configurations

In my codebase, I’ve opted for hardcoded constants like:

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

There are no separate config files or environment variables; any adjustment requires a redeployment of the code.

The hidden benefit? I can search my entire codebase for any configuration value almost instantaneously. Each pricing change is easily trackable in Git