The Three-Month Rule: A Practical Approach to Experimentation in Development

In the entrepreneurial landscape, the wisdom of Paul Graham’s mantra to “do things that don’t scale” resonates deeply, yet how do we concretely apply this philosophy in the realm of coding?

After dedicating eight months to the development of my AI podcast platform, I’ve established a straightforward strategy that I like to call the “Three-Month Rule.” This principle dictates that each unscalable hack is permitted a trial period of three months. Following this time, the hack must either demonstrate its merit and evolve into a robust solution, or it will be discarded.

As developers, we often feel compelled to design for scalability from the outset. We are well-versed in creating intricate architecture—think microservices, distributed systems, and design patterns—geared for massive user bases. However, this is a mindset better suited for large enterprises rather than startups, where attempting to scale prematurely can often lead to wasted resources.

In the startup context, investing time in scalable solutions can be a form of procrastination, as we chase audiences that have yet to materialize and troubleshoot issues that may never occur. The “Three-Month Rule” compels me to produce straightforward, albeit less-than-perfect, code that actually gets deployed, enabling me to learn firsthand what users genuinely require.

Current Infrastructure Strategies: Simplicity Over Complexity

1. Consolidated Deployment on One Virtual Machine

At present, my entire infrastructure—comprising the database, web server, background jobs, and caching—is hosted on a single $40/month virtual machine, with no redundancy and manual backups to my local system.

You might wonder how this choice could be considered wise. The reality is that within the last two months, I have gained invaluable insights into my true resource requirements—information that elaborate capacity planning documents could never provide. For instance, my AI-centric platform only peaks at 4GB of RAM. The complicated Kubernetes environment I almost built would have resulted in managing a surplus of unused containers.

When service interruptions (which have occurred twice) take place, they unveil critical information about what genuinely fails—often, it isn’t what I initially suspected.

2. Hardcoded Configurations

With configurations like these:

plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

I’ve opted out