Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech

In the tech world, especially in startups, you might have heard the phrase popularized by Paul Graham: “Do things that don’t scale.” While this advice is often circulated, few delve into the practical application of this mindset, particularly in software development. After eight months of building my AI podcast platform, I’ve adopted a straightforward yet effective framework inspired by this principle: any hack that isn’t scalable has three months to demonstrate its value. Post this period, it either evolves into a more robust solution or is discarded altogether.

As engineers, we often find ourselves gravitating towards scalable solutions—envisioning microservices and distributed systems prepared to accommodate millions of users. But in a startup environment, over-optimizing for potential users often leads to wasted resources and missed learning opportunities. My rule encourages me to write straightforward, even “imperfect” code that can be deployed quickly, allowing me to gain insight into what my users truly require.

Current Infrastructure Strategies That Work

1. Single-VM Architecture

I’m currently running my entire stack—including the database, web server, background jobs, and Redis—on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups to my local machine, it has provided me with invaluable knowledge about my actual resource requirements. Surprisingly, my platform only peaks at around 4GB of RAM, revealing that the complicated Kubernetes setup I nearly pursued would have been unnecessarily complex. Moreover, each crash has delivered practical data regarding system failures, which were often unforeseen.

2. Hardcoded Configurations

With constants hardcoded throughout my codebase—such as pricing tiers and user limits—I simplify management and deployment. Modifying any configuration necessitates a redeployment, but this has proven efficient. I can quickly search for specific values across all files, and every change is documented in my git history. In three months, I’ve altered configurations just three times, saving countless hours of potential engineering time.

3. Using SQLite in Production

Yes, my multi-user application employs SQLite, and it functions well with a database size of merely 47MB. This choice surfaced from an analysis showing that 95% of my access patterns are read operations. Had I set up a more robust database solution like Postgres from the start, I would have been wasting efforts on optimization for a situation that simply