The 3-Month Rule: A Pragmatic Approach to Non-Scalable Coding
When it comes to startup development, the often-cited advice from Paul Graham, “Do things that don’t scale,” resonates deeply. However, there seems to be a notable lack of discussion about how to effectively apply this principle in the realm of coding and infrastructure. Over the past eight months, as I’ve been crafting my AI podcast platform, I’ve formulated an enlightening approach: each unscalable solution I’ve implemented receives a three-month trial period. After this timeframe, if the concept hasn’t demonstrated its worth or is not ready for a robust build, it’s time to retire it.
As engineers, we are conditioned to think in terms of scalability from the outset. We often get caught up in the allure of meticulously designed systems—microservices, distributed architecture, and sophisticated design patterns that can manage millions of users. However, this kind of thinking tends to dominate larger companies. In a startup environment, initiating development with a scalable mindset often leads to wasted resources and time. My three-month rule compels me to opt for straightforward and, yes, imperfect code that is deployable and teachable, providing genuine insights into user behavior.
Rethinking Efficiency: My Current Infrastructure Hacks
1. Consolidated on a Single VM
Instead of relying on a multitude of services, everything—from the database to the web server—is functioning on a basic $40/month virtual machine. There’s no redundancy, and backups are done manually.
Why is this an intelligent choice? I’ve gained more insight into my resource requirements in just a couple of months than I would have from any comprehensive document. It turns out that my platform peaks at around 4GB of RAM, which means that the elaborate Kubernetes infrastructure I contemplated would have involved managing empty resources.
When disruptions occur (two times so far), the events yield valuable data about system vulnerabilities, often revealing surprises in design assumptions.
2. Simplistic Hardcoded Configurations
In my code, configuration values are directly hardcoded, like:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no external config files or environment variables, which means any changes require a straightforward redeployment.
The advantage? I can quickly search my entire codebase for configuration values. Each price alteration is meticulously tracked in Git
