Embracing the Three-Month Rule: A Practical Approach to Non-Scalable Solutions

In the entrepreneurial landscape, there’s a well-known principle from Paul Graham that encourages startups to “do things that don’t scale.” However, few discuss the practical implementation of this idea in the realms of software development. After eight months of building my AI podcast platform, I’ve crafted a straightforward framework: every non-scalable tactic I employ receives a dedicated lifespan of three months. By the end of this period, it either validates its worth and evolves into a robust solution, or it is discarded.

As engineers, we often approach challenges with a mindset geared towards creating scalable architectures from the outset. Whether it’s through complex design patterns or distributed systems, our training pushes us to prepare for high-volume traffic and extensive user bases. Yet, in the startup environment, the pursuit of scalability can easily lead to costly delays, as we find ourselves optimizing for users who may never come and addressing issues that may never arise. My three-month rule compels me to write straightforward, unconventional code that delivers value quickly and informs me of genuine user needs.

Insights on My Current Infrastructure Hacks

1. One Virtual Machine for Everything

My entire operation – including the database, web server, background jobs, and caching – runs on a single $40-per-month virtual machine (VM). The simplicity of this setup comes with no redundancy and manual backups to my local system.

This method has yielded invaluable insights about my actual resource requirements in just two months, far surpassing any conventional capacity planning document. I discovered that my “AI-rich” platform only requires 4GB of RAM at peak usage. The complex Kubernetes architecture I almost implemented? It would have entailed managing empty containers with minimal traffic.

Each time the system crashes (which has happened twice), I gain real-world insight into the underlying failures – often revealing unexpected vulnerabilities.

2. Hardcoded Configuration Settings

I’ve adopted a practice of hardcoding key configuration details, such as pricing tiers and user limits, directly into the codebase. While this means redeploying for any updates, it has its advantages.

The beauty of this approach? I can quickly search the entire codebase to locate any configuration value. Every price adjustment is traced in the Git history, and any changes undergo a code review process (carried out by myself). Constructing a dedicated configuration service would have taken a week, whereas I’ve altered these values just three times in three months