The 3-Month Rule: A Practical Approach to Building Unscalable Solutions
In the startup ecosystem, you’ve probably heard the timeless advice from Paul Graham: “Do things that don’t scale.” However, when it comes to implementation, particularly in the realm of coding, the conversation often fizzles out.
After spending eight months constructing my AI podcast platform, I’ve devised a straightforward yet effective framework: any unscalable approach I adopt gets a trial period of just three months. During this time, it must either demonstrate its worth and warrant further development or face elimination.
As engineers, we are often conditioned to focus on creating scalable architectures from the outset—envisioning grand designs involving microservices and distributed systems, all while anticipating millions of users. However, in a startup context, such foresight can lead to unnecessary procrastination. Instead of optimizing for users who haven’t yet arrived, I employ a three-month rule to develop simple, direct, albeit imperfect code. This allows me to understand my actual user needs more intimately.
Insights from My Current Infrastructure Hacks
1. Single Virtual Machine Setup
All the components—database, web server, background jobs, Redis—run on a single $40/month virtual machine. While it lacks redundancy and relies on manual backups to my local system, this approach has provided invaluable insights. Within just two months, I’ve learned about my true resource demands. Contrary to expectation, my AI-centric platform only peaked at 4GB RAM. The complex Kubernetes setup I contemplated would have led to managing empty containers instead of real traffic.
When my system crashes (which has happened twice so far), I gain concrete insights into what isn’t functioning as anticipated. Spoiler alert: it’s rarely what I thought.
2. Embracing Hardcoded Configuration
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Instead of relying on configuration files or environment variables, I use hardcoded constants scattered throughout my code. This means any change necessitates a redeployment, but there’s a silver lining. I can quickly scan my entire codebase for configuration values, and every price adjustment is meticulous tracked in git history. In the last three months, I’ve modified these values only three times, which takes 15 minutes to redeploy, compared to the 40 hours it would take to create a configuration service.
**3
