Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Development

In the realm of entrepreneurship and software development, the well-known mantra from Paul Graham, “Do things that don’t scale,” is often quoted but rarely implemented effectively. As a founder navigating the complexities of building an AI podcast platform for the past eight months, I have devised a unique approach to incorporating this advice into my coding practices. My methodology is straightforward yet profound: each unscalable solution I create is given a lifespan of just three months. After this period, I evaluate whether it demonstrates clear value for the project or if it should be retired.

The Challenge of Scaling Early

As engineers, we are conditioned to prioritize scalable solutions right from the outset. We often inquire about design patterns, microservices, and distributed systems, imagining how to cater to millions of potential users. However, this often leads to complex setups that can act as a barrier to innovation in a startup setting. Focusing on scalability at this stage may result in what feels like unnecessary procrastination. Instead of optimizing for users that haven’t yet arrived, the 3-month rule compels me to write straightforward, usable code that can be deployed quickly, allowing me to truly understand my users’ needs.

Current Infrastructure Hacks and Their Unexpected Benefits

1. One VM for Everything

My entire system—database, web server, background jobs, and caching—resides on a singular $40/month virtual machine. While this setup offers zero redundancy and requires manual backups, the insights I’ve gained in just a couple of months are invaluable. I’ve tracked my resource utilization closely, discovering my platform peaks at just 4GB of RAM. The complex container management system I had initially considered would have been an unnecessary expenditure of time and resources.

When issues arise (and they have), I acquire actionable insights about the root causes, which are often unexpected.

2. Simplistic Hardcoded Configuration

Instead of relying on configuration files or environment variables, I’ve opted for hardcoded constants within my codebase. Yes, this means redeploying whenever I want to change a setting, but my ability to quickly search for configuration values throughout the code is a hidden advantage. Each pricing adjustment is meticulously tracked through version history, allowing for straightforward changes without overwhelming engineering demands.

3. SQLite as a Production Database

In a bold move, I am employing SQLite for my multi-user application, micro-optimizing the experience.