Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Tech
In the world of startups, the advice from renowned entrepreneur Paul Graham to “do things that don’t scale” often resonates strongly. However, the process of applying this philosophy in the realm of coding remains less discussed. After eight months of developing my AI podcast platform, I’ve crafted a straightforward framework: any non-scalable solution has a lifespan of three months. After this period, it must either demonstrate its value and be developed further, or be phased out entirely.
As software engineers, we are often conditioned to focus on building scalable solutions from the outset. We delve into advanced design patterns, microservices, and distributed systems, all designed to handle vast numbers of users. While such architecture is critical for larger enterprises, in a startup environment, creating scalable code too early can simply be a costly form of procrastination. We’re often optimizing for users that don’t yet exist, and problems that may never arise. My three-month strategy compels me to produce straightforward, albeit “imperfect,” code that delivers results and reveals the true needs of users.
Current Infrastructure Hacks: Innovations Born from Constraints
1. Single VM Architecture
I run my entire stack—database, web server, background tasks, and caching—on a single, cost-effective VM. This approach may seem reckless due to the lack of redundancy and manual backups, but it has provided invaluable insights. Over the past two months, I’ve gained a clearer understanding of my resource requirements than any extensive planning document could have offered. My “AI-laden” platform, for instance, peaks out at just 4GB of RAM, and the intricate Kubernetes setup I contemplated would have been bogged down managing idle resources. Each crash has yielded real data that has informed my future development.
2. Simplified Configuration Management
My approach to configuration management might raise eyebrows. With hardcoded values scattered throughout my code, I’ve opted for a rudimentary system over complex config files. This simplicity allows me to quickly locate and modify configuration parameters using basic code search tools. In just three months, I’ve altered some values a mere three times, saving hours of potential engineering work. The ability to review changes in version control reinforces my workflow without necessitating a complex configuration service.
3. SQLite as a Database Solution
Surprisingly, I’ve chosen SQLite for my multi-user application. With a database size of only 47MB, it efficiently handles up
