Embracing the 3-Month Rule: A Pragmatic Approach to Rapid Development
In the world of startups, the mantra often resonates: “Do things that don’t scale,” as famously advised by Paul Graham. However, there’s a void in the conversation when it comes to practical strategies for integrating this principle into software development. After dedicating eight months to the creation of my AI podcast platform, I’ve established a straightforward framework: any non-scalable hack I implement gets a lifespan of just three months. At the end of this period, it either proves its worth and gets refined into a sustainable solution, or it gets discarded.
As engineers, we are conditioned to develop scalable architectures from the outset, focusing on design patterns, microservices, and distributed systems capable of managing vast user bases. Yet, in the startup realm, this approach can lead to costly delays. Often, we find ourselves optimizing for potential users who don’t even exist yet or addressing issues that may never arise. My three-month rule compels me to write straightforward, even “imperfect,” code that can be deployed quickly, allowing me to better understand the needs of my users.
My Current Infrastructure Techniques: Why They Make Sense
1. Consolidation on a Single VM
I host my complete stack—including the database, web server, background jobs, and Redis—on a single virtual machine for $40 a month. There’s no redundancy, and backups are done manually to my local drive.
This approach may sound reckless, but it has provided invaluable insights into my actual resource requirements. Within just two months, I’ve learned that my “AI-heavy” platform only requires 4GB of RAM at peak usage. The complex Kubernetes setup I considered would have meant managing inactive containers. When my setup does fail (and it has twice), I gain real insights into what goes wrong—typically surmounting my expectations.
2. Hardcoded Configuration Values
Instead of employing config files and environment variables, I utilize hardcoded constants across my codebase:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Modifying a value requires a redeployment, but there’s a hidden advantage here: I can quickly search my codebase for any configuration item. Each price alteration is documented through my git history, and every change undergoes my personal review.
Creating a configuration
