Embracing the 3-Month Rule: A Technical Framework for Non-Scalable Solutions
In the startup world, the name Paul Graham often comes up, especially for his mantra, “Do things that don’t scale.” While this advice is widely acknowledged, the challenge lies in its practical implementation, especially in coding.
After dedicating eight months to developing my AI podcast platform, I’ve established an effective framework: each temporary, non-scalable hack has a lifespan of just three months. At the conclusion of this period, each solution must either demonstrate its worth and evolve into a robust feature or be discarded.
It’s important to recognize that as engineers, we are conditioned to create scalable solutions from the outset—focusing on design patterns, microservices, and distributed architectures that are capable of accommodating vast user bases. However, this is more aligned with large corporations than with the nimble environment of a startup. In fact, pursuing scalability too soon can often result in costly procrastination, as we end up optimizing for hypothetical users and addressing issues that may never arise. My 3-month rule compels me to implement straightforward, albeit imperfect code that is functional and instructive, illuminating what users genuinely need.
Current Infrastructure Hacks: Strategic Choices for Learning
1. Single Virtual Machine Setup
I host my entire application—including the database, web server, background jobs, and caching—on a single $40/month virtual machine. There’s no redundancy, and I perform manual backups.
The brilliance of this approach lies in the insights I’ve gained about my actual resource utilization. In the two months since I adopted this model, I’ve come to understand that my “AI-intensive” platform only requires 4GB of RAM at peak usage. The complex Kubernetes architecture I nearly established would have merely involved managing idle containers. When the system has crashed (twice, to be precise), I obtained valuable data on the breaking points—usually surprising and far from what I anticipated.
2. Hardcoded Configuration
My configuration is straightforward:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There’s no configuration file or reliance on environment variables; instead, constants are directly embedded in the code. Adjusting any configuration necessitates a redeployment.
The hidden advantage? I can quickly search my entire codebase for any configuration item. Every price adjustment is
