The 3-Month Experiment: A Pragmatic Approach to Non-Scalable Solutions

In the startup world, Paul Graham’s advice to “do things that don’t scale” often sounds straightforward, but putting it into practice—especially from a technical standpoint—can be tricky. Over the past eight months, as I’ve been developing my AI podcast platform, I’ve implemented a unique strategy that I call the “3-Month Rule.” This approach allows every unscalable solution to exist for a trial period of three months, compelling me to evaluate whether it adds significant value or if it should simply be scrapped.

Understanding the Paradigm Shift in Engineering

Traditionally, engineers are trained to prioritize scalability from the outset, crafting elaborate architectures featuring microservices and distributed systems. However, in the realm of startups, focusing on scalability too early can become a form of costly procrastination. Too often, we find ourselves crafting solutions for hypothetical users or addressing concerns that may never materialize. My three-month framework encourages me to prioritize pragmatic, straightforward coding that often goes against conventional wisdom but provides invaluable insights into real user needs.

Key Infrastructure Hacks Supporting My Strategy

Here are a few of the key infrastructure choices I’ve made using this framework, showcasing their benefits and the lessons learned:

1. Consolidating Resources on a Single VM
I’ve opted to run all aspects of my platform—database, web server, background tasks, and caching—on a single $40/month virtual machine. Yes, it lacks redundancy and relies on manual backups to my local system, but this simplicity has revealed critical insights into my actual resource needs. I’ve discovered that my platform rarely exceeds 4GB of RAM. A complex Kubernetes framework I initially considered would have led to unnecessary management of unused resources. When the system crashes, I get actionable data about performance, often revealing unexpected vulnerabilities.

2. Hardcoded Values as Configuration
My current configuration setup involves hardcoding parameters directly in my codebase—such as:

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

This method eliminates the complexity of configuration files or environmental variables. While it may seem limiting, this approach allows rapid access and tracking of configuration changes through version control. In just three months, I have modified these settings a mere three times—an efficient use of time compared to building a full-fledged configuration service.

3. Using SQLite for Production