Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech
In the tech world, advice often echoes through the halls, notably Paul Graham’s famous maxim: “Do things that don’t scale.” While this sentiment is widely acknowledged, the process of applying it, especially in coding, is rarely discussed. As someone who has spent the last eight months developing an AI podcast platform, I’ve crafted a straightforward yet effective methodology: every non-scalable solution I implement is given a lifespan of just three months. After this period, it either proves its utility and gets developed further, or it’s discarded altogether.
As engineers, our training typically steers us towards building solutions that can handle scalability from the get-go. We often find ourselves wrapped up in employing design patterns, microservices, and distributed systems—architectures designed to accommodate millions of users. However, this mindset often reflects that of larger corporations.
In a startup environment, focusing on scalable solutions can lead to expensive procrastination. We may end up optimizing for potential users who may never arrive, addressing problems that might not exist. My 3-month rule encourages me to write straightforward, direct, and sometimes “imperfect” code. This approach ensures that I deliver actual products and provides valuable insights into what my users genuinely require.
Here are some of my current infrastructure hacks and the wisdom behind them:
1. Consolidated Resources on One Virtual Machine
I’ve opted to run everything—database, web server, background tasks, Redis—on a single $40/month virtual machine without redundancy, relying on manual backups to my local machine.
Why is this a smart strategy? In just two months, I’ve gained a clearer understanding of my actual resource needs than any lengthy capacity planning document could provide. The reality of my “AI-heavy” platform is that it peaks at 4GB of RAM. My initial plans for a complex Kubernetes setup would have led to managing idle containers.
Whenever the system crashes (which has happened twice), I receive pertinent data about what actually goes wrong—surprising me every time with unexpected insights.
2. Hardcoded Configuration for Simplicity
Instead of relying on configuration files or environment variables, I use constants directly in my code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this may sound
