Embracing the 3-Month Rule: A Practical Approach to Coding in Startups
In the world of tech startups, one mantra stands out: “Do things that don’t scale,” a piece of advice famously given by Paul Graham. However, the intricacies of actually applying this concept, especially in coding, often go unnoticed. Drawing from my personal experience of developing an AI podcast platform over the past eight months, I’ve formulated a straightforward framework: unscalable solutions are granted a lifeline of just three months. After this period, they either demonstrate value through concrete results and are built out properly, or they are discarded.
The Contradiction in startup Development
As developers, we are typically conditioned to craft scalable solutions from the outset. We get caught up in sophisticated architecture involving design patterns, microservices, and distributed systems—concepts that are indeed vital for multi-user applications. However, in the startup ecosystem, striving for scalability can lead to costly delays, often focusing on hypothetical users and irrelevant challenges. My three-month rule encourages me to produce straightforward, if not imperfect, code that gets delivered to users quickly, enabling genuine insights into their needs.
My Practical Hacks and Their Purpose
1. Consolidated Operations on a Single VM
Currently, my infrastructure runs entirely on a single $40/month virtual machine that hosts the database, web server, background tasks, and caching through Redis—all without redundancy and backed up manually. This approach, often mistaken for negligence, has allowed me to accurately gauge my resource demands in just two months. I discovered that my “AI-intensive” platform only peaks at 4GB of RAM. The elaborate Kubernetes architecture I almost opted for would have required managing resources that were never utilized. Plus, when crashes occurred (and they have), I gained firsthand knowledge of the specific issues—insights I would have missed with more complex systems.
2. Simplified Configuration Management
Instead of using configuration files or environment variables, I’ve hardcoded critical values directly into my code. Each adjustment necessitates redeployment, but this simplicity is a strategic benefit. I can quickly grep my entire codebase for configuration values, track changes via git history, and review updates instantaneously. Creating a dedicated configuration management service could take a week; however, I have only needed to modify the constants three times in three months, resulting in a mere 15 minutes of work instead of 40 hours.
3. Using SQLite for Production
Yes,
