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

In the tech world, we’ve all encountered the familiar wisdom from Paul Graham: “Do things that don’t scale.” However, the practical implementation of this advice, especially in the realm of coding, often goes unaddressed.

Over the past eight months, while creating my AI podcast platform, I devised a straightforward yet effective framework: any unscalable workaround I implement has a lifespan of just three months. After this period, if the solution proves its worth, it gets a proper overhaul; otherwise, it’s time to let it go.

Rethinking Scalability in Startups

As engineers, we often strive to develop “scalable” solutions right from the outset—embracing complex architectural patterns and systems designed to handle millions of users. However, in the context of a startup, these ambitions can quickly devolve into costly procrastination, focusing on users who aren’t yet on the radar and solving issues that may never arise. By adhering to my 3-month rule, I can concentrate on crafting straightforward, albeit imperfect, code that gets the job done and reveals the genuine needs of my users.

Current Innovative Infrastructure Strategies

1. Consolidated Operations on a Single VM

Instead of spreading out functionalities, my platform operates entirely on one $40/month virtual machine, hosting the database, web server, background jobs, and Redis. If this sounds reckless, consider the benefits: in just two months, I’ve gained invaluable insights into my resource requirements. My initial fears of overwhelming demand have been eased; my “AI-heavy” application operates comfortably on just 4GB of RAM. If I had rushed into a complex setup with Kubernetes, I would have wasted time managing unnecessary resources. Each crash (yes, there have been a couple) provided data about the real points of failure, frequently unexpected.

2. Simplified Hardcoded Configurations

I’ve opted for hardcoded constants across my codebase instead of elaborate configuration files or environment variables. Adjusting something? That requires a redeploy, which I’ve only done minimally—three times in three months. In today’s world, spending a few minutes redeploying saves hours of engineering effort that would have been consumed by creating a dedicated configuration service.

3. Utilizing SQLite for Production

While running a multi-user web application on SQLite might raise eyebrows, it’s been surprisingly effective. My database is a mere