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

In the tech world, many often cite Paul Graham’s wisdom on the importance of “doing things that don’t scale.” However, the challenge lies in effectively translating that advice into actionable practices, especially when it comes to coding. Having dedicated the last eight months to developing my AI podcast platform, I have devised a straightforward framework: every unscalable hack has a life expectancy of just three months. After this period, the hack must either demonstrate its worth and be refined or be phased out entirely.

As engineers, our instinct is to focus on creating scalable solutions from the outset. We delve into design patterns, microservices, and robust architecture suited for massive user bases. However, that mindset often leads to a form of procrastination, especially in a startup environment where users may still be a distant dream. The three-month rule prompts me to adopt a more hands-on approach, allowing me to write straightforward, albeit imperfect, code that actually gets deployed and reveals true user needs.

My Practical Infrastructure Hacks and Their Underlying Wisdom

1. Consolidated Operations on a Single VM

I’ve centralized everything—database, web server, background jobs, and Redis—on one $40/month virtual machine, with no redundancy and manual backups to my local storage. This might seem reckless, but here’s the brilliance: in just two months, I’ve gained greater insight into my true resource requirements than any capacity planning exercise could provide. My platform’s peak usage barely hits 4GB of RAM, making the complex Kubernetes setup I nearly pursued unnecessary.

The few crashes I’ve encountered have offered invaluable data about failure points—surprisingly, it’s never what I anticipated.

2. Hardcoded Configuration for Simplicity

In my code, configuration values such as pricing and user limits are hardcoded within the files. This means that any modification requires a redeployment. While this may seem inefficient, it allows me to quickly search and track changes across my entire codebase. Thus far, I’ve made only three pricing adjustments in three months, resulting in minimal deployment time compared to the weeks it would take to build a configuration management service.

3. Using SQLite for a Multi-User Application

You read that correctly: my multi-user application operates on SQLite, and it manages a database size of merely 47MB. Surprisingly, it supports up to 50 concurrent users seamlessly