The 3-Month Rule: A Pragmatic Approach to Non-Scalable Development

In the tech community, Paul Graham’s famous advice to “do things that don’t scale” often resonates, but there’s a noticeable gap in discussions about how to effectively implement this mindset—especially in coding. Drawing from my experience building an AI podcast platform over the past eight months, I’ve established a straightforward framework: every non-scalable hack has a life span of three months. After this period, it must either demonstrate its value and be properly developed or be discarded.

The Reality of startup Engineering

As engineers, we are frequently conditioned to focus on crafting scalable solutions right from the outset. We delve into complex architectures, incorporating design patterns, microservices, and distributed systems—all tailored to manage millions of users. Yet, this line of thinking is typically rooted in big company culture.

In the context of a startup, obsessing over scalability can amount to costly procrastination. We find ourselves optimizing for potential future users instead of addressing current needs. The three-month rule I have adopted compels me to write straightforward, often “imperfect” code that gets deployed, providing invaluable insights about what users truly require.

My Strategic Infrastructure Hacks

1. Consolidated Resources on a Single VM

I operate my entire project infrastructure—database, web server, background jobs, and Redis—on one $40/month virtual machine. This setup lacks redundancy, with backups done manually to my local system.

Why does this approach work? In just two months, I’ve gained more understanding of my actual resource consumption than any planned capacity document could have offered. For instance, I discovered that my “AI-heavy” platform typically only requires 4GB of RAM. The large-scale Kubernetes framework I nearly implemented would have ended up managing many unused resources. Moreover, whenever there’s a crash (which has happened twice), I gather real-time data on what fails—often, it’s never what I would have anticipated.

2. Simple Hardcoded Configuration

I store configuration settings directly in the code:

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

This strategy eliminates the need for config files or environment variables. Making changes involves redeploying, yet it empowers me to quickly search the entire codebase and track every price adjustment through version control. Constructing a