The 3-Month Rule: A Practical Approach to Non-Scalable Coding

In the world of startup development, advice like Paul Graham’s “do things that don’t scale” is often echoed, yet the application of this principle in the realm of coding rarely receives the attention it deserves. Having spent the last eight months constructing my AI podcast platform, I’ve crafted a straightforward yet effective framework: I give every non-scalable solution three months to either demonstrate its value or be shelved.

As engineers, we’re frequently trained to pursue scalable solutions from the very beginning—think design patterns, microservices, and complex distributed systems designed for vast audiences. However, this mindset can become counterproductive, especially in a startup context where crafting scalable code may inadvertently lead to procrastination and wasted resources. My three-month rule compels me to adopt simpler, more direct coding practices that lead to rapid deployment and insightful user feedback.

Current Infrastructure Strategies: Smart Simplicity

Here’s an overview of some current infrastructure strategies I’ve implemented that might seem unconventional, yet prove to be incredibly beneficial:

1. Single VM for Everything

I run my entire operation—including the database, web server, background jobs, and Redis—on a single $40/month virtual machine. While this approach features minimal redundancy and requires manual data backups, it has offered invaluable insights into my actual resource needs far beyond what any capacity-planning document could provide.

For example, I’ve discovered that my “AI-heavy” platform typically requires only 4GB of RAM. The extensive Kubernetes setup I nearly initiated would have resulted in resource management for unused containers. With the VM crashing a couple of times, I gathered real data about system failures and learned that these incidents often stemmed from unexpected issues.

2. Hardcoded Configuration Values

Instead of using configuration files or environment variables, I keep all my constants—such as pricing tiers and maximum user capacity—hardcoded throughout the codebase. While this may appear simplistic, it offers a unique benefit: I can quickly search for configuration values throughout the entire codebase, and each change is precisely tracked in version control.

Building a complex configuration service would have taken up to a week. In practice, I’ve modified these values only three times in three months, leading to minimal redeployment time compared to the hours that would have been needed for more elaborate solutions.

3. Using SQLite in Production

Surprisingly, I’m utilizing SQLite for my multi-user web application. Given that the database size is