Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions

In the entrepreneurial tech space, you may have come across the mantra from Paul Graham: “Do things that don’t scale.” While many discuss the philosophy behind this approach, few delve into how it can be effectively applied, particularly in the realm of programming and development.

After dedicating the last eight months to constructing my AI podcast platform, I have adopted a straightforward framework: every temporary, non-scalable solution I implement is given three months to prove its worth. Post the three-month mark, these hacks either become foundational elements of the platform—transformed into robust systems—or they are omitted altogether.

The Challenge of Scalable Thinking

As engineers, we are often schooled in the importance of scalable architecture. We learn to deploy design patterns, microservices, and distributed systems intended for handling substantial user loads. However, this mindset frequently serves established companies rather than startups. In a startup environment, working on scalable architecture may simply defer critical decisions, diverting attention toward hypothetical user bases and non-existent issues.

Implementing my three-month rule compels me to focus on creating straightforward, albeit imperfect, code that yields tangible results. This approach ultimately clarifies the actual needs of my users.

Current Infrastructure Strategies: Why They Work

1. All-in-One Virtual Machine (VM)
I operate my entire platform—from the database to the web server—on a single VM costing just $40 per month. While this setup lacks redundancy and relies on manual backups, it has provided invaluable insights. Within two months, I learned my system peaks at around 4GB of RAM, negating the need for a complex, resource-heavy Kubernetes infrastructure that might not have been utilized at all. Each incident of downtime reveals genuine issues that require addressing, often not what I initially anticipated.

2. Hardcoded Variables
Instead of employing configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. This methodology simplifies my workflow: searching for configuration values is swift, every change is logged in version control, and updates can be managed with minimal redeployment time. In three months, I’ve made only three adjustments to pricing tiers and configurations—saving hours of engineering effort that would have been consumed by creating a separate configuration service.

3. SQLite in Production
My decision to use SQLite for a multi-user application may raise eyebrows, but with a database size of just