Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Development
In the world of startups, the advice from renowned entrepreneur Paul Graham — “Do things that don’t scale” — is often discussed but seldom implemented effectively within the coding realm. After eight months of developing my AI podcast platform, I’ve created a straightforward framework that integrates this principle: every hack that doesn’t scale is given a lifespan of three months. By the end of that period, each approach must either demonstrate its value and be rebuilt, or face extinction.
Rethinking Scalability
As software engineers, we’re conditioned to prioritize scalable solutions from the get-go. We often get wrapped up in utilizing advanced design patterns, microservices, and distributed systems—all aimed at sustaining millions of users. However, this mindset is more suited to large enterprises than to the dynamic environment of a startup, where dedicating resources to scalability can merely delay addressing real user needs.
My three-month rule compels me to produce simple, even “suboptimal,” code that can be deployed quickly and effectively, enabling a deeper understanding of user requirements.
Current Unscalable Tricks: Strategic Decisions
1. Unified Virtual Machine
I currently run my entire infrastructure — including the database, web server, background jobs, and caching — on a single virtual machine for just $40 a month. This means no redundancy and manual backups, but it has proven invaluable. Within two months, I’ve gained more insight into my resource requirements than any capacity planning report could provide. For instance, I’ve discovered that my platform peaks at just 4GB of RAM, revealing that an elaborate Kubernetes setup would have been unnecessary.
2. Simplistic Hard-Coded Configurations
Instead of relying on configuration files or environment variables, I’ve opted for hard-coded constants within my codebase. While this might seem impractical at first glance, it brings with it remarkable efficiency: a simple search allows me to track and manage changes quickly, and updates are hassle-free. Over the past three months, I’ve made just three changes, requiring a brief redeployment rather than extensive engineering hours.
3. SQLite for Multi-User Access
I’m utilizing SQLite to power my web application, and surprisingly, it performs admirably even with multiple users. This choice has taught me that my usage patterns predominantly involve reading data. Had I implemented a more complex solution like Postgres from the beginning, I would likely have wasted time optimizing for issues
