Embracing the 3-Month Rule: A Practical Approach to Scalable Solutions

In the world of startups, advice from industry gurus often resonates deeply. One phrase from Paul Graham stands out: “Do things that don’t scale.” However, implementing this concept in the realm of coding can be challenging, given the prevalent focus on scalability in software development.

After dedicating the past eight months to building my AI podcast platform, I’ve cultivated a straightforward but effective framework: any unscalable hack is given a lifespan of just three months. At the end of this period, it either proves its worth and transitions to a robust solution, or it is phased out.

As engineers, our instinct is to create scalable systems from the get-go. We are trained to consider elaborate design patterns, microservices, and distributed systems—architectures capable of accommodating millions of users. However, this mindset can often lead startups down a costly path of procrastination, where we invest time in optimizing for potential users that don’t yet exist and grappling with challenges that may never arise. My three-month rule encourages the development of straightforward, if imperfect, code that not only functions but also provides critical insights into user needs.

Current Unscalable Solutions and Their Surprising Benefits

1. Consolidated Infrastructure on One Virtual Machine

I host my database, web server, background jobs, and Redis all on a single virtual machine that costs just $40 per month, with no redundancy and manual backups.

Why is this an effective strategy? In just two months, I’ve gained a clearer understanding of my actual resource requirements than any planning document could have provided. For instance, my “AI-heavy” platform typically peaks at 4GB of RAM, rendering the complex Kubernetes setup I almost implemented unnecessary.

Every time my system crashes—a total of twice so far—I gain valuable data about the failure points, which are rarely what I initially anticipated.

2. Embracing Hardcoded Configurations

Exemplified by constants like:

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

I’ve opted for hardcoded configurations rather than using separate configuration files or environment variables. This may seem primitive, but it allows me to quickly search my entire codebase for any config value. Moreover, any change requires only a brief redeployment.

Setting up a configuration service