Embracing the 3-Month Rule: My Approach to Unconventional Development Tactics

It’s well known in our startup culture that iconic entrepreneur Paul Graham advocates for “doing things that don’t scale.” While this mantra is commonly referenced, there’s often a lack of practical guidance on how to apply it, especially for tech entrepreneurs like myself.

Over the past eight months, as I’ve worked on my AI podcast platform, I’ve established a straightforward framework: every unconventional development hack I implement is given a lifespan of three months. At the end of this period, each solution must either demonstrate its value and evolve into a more structured approach, or it will be discarded.

As software engineers, we often feel compelled to create scalable solutions from the outset. We gravitate towards sophisticated design patterns, microservices, and expansive architectures—all ideal for supporting millions of users. However, this approach can be more suited to larger, established companies than to agile startups.

In the fast-paced startup environment, creating scalable code can sometimes turn into an exercise in procrastination. We may find ourselves optimizing for hypothetical users and addressing issues that may not even arise. My three-month rule encourages me to produce straightforward, even “messy,” code that allows me to gather real insights about user needs.

Current Infrastructure Hacks and Their Strategic Value

1. Single VM for Everything

I’ve consolidated my database, web server, and background jobs onto a single $40/month virtual machine, forgoing redundancy and opting for manual backups to my local drive.

This decision has yielded invaluable insights into my resource needs. Within just two months, I’ve discovered that my “AI-heavy” platform peaks at only 4GB of RAM. The complex Kubernetes setup I nearly implemented would have resulted in unnecessary management of idle containers. Each crash, of which there have been a few, has provided clarity on failure points I never anticipated.

2. Hardcoded Configuration Values

In my code, you’ll find critical constants such as:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no config files or environment variables—just hardcoded values dispersed throughout the codebase. Modifying these constants necessitates a redeployment.

The advantage of this setup is profound: I can swiftly search my entire code for any configuration value. Each pricing change is meticulously documented in my git history,