The 3-Month Experiment: A Pragmatic Approach to Developing Unscalable Solutions

In the world of startups, one phrase often comes up: “Do things that don’t scale,” famously advocated by Paul Graham. While this advice is widely recognized, the implementation of this principle in the realm of coding often remains unaddressed. After eight months of building my AI podcast platform, I’ve established a straightforward framework that I like to call the “3-Month Rule.” The premise is simple: any workaround that cannot scale effectively has a three-month lifespan to prove its worth. After this period, it either gets the enhancement it deserves or is discarded entirely.

Unlearning Conventional Wisdom

As engineers, we are often conditioned to create scalable solutions from day one—think design patterns, microservices, and sophisticated architectures capable of accommodating millions of users. However, this is primarily a perspective cultivated in larger corporations. In a startup environment, pursuing scalability prematurely can lead to unnecessary expenses and wasted effort on features that may not be needed. My 3-Month Rule compels me to embrace simplicity and directness, allowing me to produce “subpar” code that actually delivers insights into user needs.

Current Implementation: Infrastructure Hacks that Work

1. Single VM Setup

All components—database, web server, background tasks, and Redis—are hosted on a single $40-a-month virtual machine. With no redundancy and manual backups performed to my local machine, the approach may seem reckless at first, yet it has yielded remarkable insights. Within just two months, I gained an understanding of my resource needs that no elaborate capacity planning ever could provide. For instance, my “AI-intensive” platform peaks at merely 4GB of RAM. Had I opted for a complex Kubernetes infrastructure, I would have dealt with managing numerous empty containers.

2. Hardcoded Configurations

Instead of using configuration files or environment variables, I rely on constants dispersed across my codebase:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100

Altering any of these values necessitates a code redeployment, but the trade-off is worth it. By hardcoding configurations, I can easily search through the codebase for any value and track changes through git history. Changing prices has occurred only three times in three months—approximately 15 minutes of redeployment versus a week of engineering for a configuration service.