Embracing the 3-Month Rule: A Strategic Approach to Building Unscalable Solutions

In the world of startups, it’s well-documented that Paul Graham advocates for the idea of “doing things that don’t scale.” However, the practical application of this concept within software development is often overlooked. After spending the past eight months nurturing my AI podcast platform, I’ve established a straightforward framework for navigating the challenges of unscalable solutions: each hack is given a three-month lifespan. After this period, it must either demonstrate its value and become a robust solution or be discarded.

As engineers, we tend to gravitate towards building scalable architectures from the outset—think sophisticated design patterns, microservices, distributed systems, and the like. While these structures are essential for large organizations, they can hinder progress in a startup environment. The pursuit of scalability can lead to unnecessary complications and delayed implementations, especially when we are still trying to understand our users’ needs.

This three-month rule compels me to write simpler, less elegant code that allows me to launch quickly and, crucially, learn from user interactions. Here are a few current infrastructure hacks I’m using, along with the rationale behind their effectiveness:

1. Single Virtual Machine (VM) Setup

I’ve consolidated all services—database, web server, background jobs, and caching—onto a single $40/month VM. While it lacks redundancy and relies on manual backups, this approach has provided profound insights into my resource usage over the past two months. Instead of over-engineering with an elaborate Kubernetes setup, I’m gathering real data on my needs while learning that my “AI-intensive” platform rarely exceeds 4GB of RAM usage. When crashes occur, which they have on a couple of occasions, I receive immediate feedback on the root causes—insights that often surprise me.

2. Hardcoded Configuration Values

Instead of using configuration files or environment variables, I’ve opted for hardcoded constants:

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

This means changing any configuration necessitates a redeployment, which, paradoxically, has proven liberating. I can quickly search the entire codebase for any constant, ensuring that updates are documented in version history and reviewed—by myself. The time I save through this method, compared to developing a dedicated configuration