Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Coding for Startups
In the ever-evolving landscape of startup development, one piece of wisdom often stands out: “Do things that don’t scale.” Coined by Paul Graham, this advice is well-known, yet there’s a surprising lack of discussion around how to effectively apply it within the realm of coding.
During my eight months of developing an AI podcast platform, I’ve stumbled upon a straightforward framework that I now swear by: each unscalable hack is given a lifespan of just three months. After this period, it must either demonstrate its worth and be properly implemented, or it will be removed from the project.
It’s a common trend among engineers to prioritize scalable solutions right from inception. We are often tempted by the allure of sleek design patterns, microservices, and distributed systems—all intended to handle millions of users. But this mindset predominantly caters to larger companies and can lead to unnecessary delays in a startup setting. At this stage, focusing on scalability may be a form of costly procrastination, as we are optimizing for hypothetical future users rather than addressing current user needs. With my 3-month rule, I find myself writing straightforward, albeit imperfect code that actually gets deployed, allowing me to understand what users truly require.
My Current Infrastructure Hacks: Smart Decisions in Disguise
1. Consolidated Infrastructure on a Single VM
I operate my database, web server, background jobs, and Redis all on a single $40/month virtual machine, with no redundancy and manual backups to my local machine.
This might seem reckless, but it’s been invaluable in helping me truly grasp my resource requirements in just two months—far better than any capacity planning document would have. I’ve learned that my “AI-heavy” platform operates within a peak of 4GB RAM. Had I gone ahead with a complex Kubernetes setup, I would have been managing empty containers instead of refining my core functionality.
When the system has crashed (which has happened twice), I’ve gained real insights into the actual causes of failure—insights that typically defy my initial expectations.
2. Hardcoded Configuration Values
Instead of relying on configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase:
“`python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = “gpt-
