Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions

In the entrepreneurial realm, Paul Graham’s advice to “do things that don’t scale” is often cited, but seldom dissected, especially in the context of software development. After eight months of building an AI podcast platform, I’ve adopted a straightforward yet effective strategy: every temporary workaround or unscalable hack is given a lifespan of just 90 days. Following this period, it’s either validated and rebuilt properly, or it’s time for it to go.

The conventional engineering mindset emphasizes scalable solutions from the outset. Frameworks, microservices architectures, and complex systems designed for high user volumes tend to dominate our thinking. However, this approach can become a costly exercise in procrastination, particularly in a startup environment where real users are often only a distant vision. My 3-month rule compels me to prioritize writing simple, even suboptimal code that can be rapidly deployed, allowing me to discern what users genuinely need through real-world feedback.

Current Infrastructure Strategies: Smart Moves for Learning

1. Consolidated Operations on a Single VM

I’ve chosen to run my entire stack—including the database, web server, and background jobs—on a single $40-per-month virtual machine. This approach lacks redundancy and supports manual backups directly to my local machine.

Why this works: In just two months, I’ve gained insights regarding my actual resource demands that would have otherwise eluded me through traditional capacity planning documents. Rather than launching into an elaborate Kubernetes setup—only to manage idle containers—I’ve discovered that my platform peaks at 4GB of RAM. Each crash has provided valuable data about unexpected failure points, allowing me to understand the system more deeply.

2. Hardcoded Configuration Strategies

Configuration values are directly embedded within the code:

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

This means no separate configuration files or environment settings exist. When a change is needed, it involves a redeployment.

The advantage: I can quickly search the entire codebase for any configuration value and track changes via Git history. Over the last three months, I’ve made just three alterations, resulting in 15 minutes of deployment time instead of the 40 hours it would take to engineer a dedicated configuration service.

**3. Utilizing SQLite