Home / Business / The 3-Month Rule: My Technical Framework for Doing Things That Don’t Scale

The 3-Month Rule: My Technical Framework for Doing Things That Don’t Scale

Embracing the 3-Month Rule: A Pragmatic Approach to Development at Startups

In the world of tech startups, the mantra of “doing things that don’t scale” often echoes, yet the steps to effectively apply this advice in programming remain under-discussed. My ongoing journey in building an AI podcast platform over the last eight months has led me to formulate a unique framework: every unscalable approach has a lifespan of just three months. After this period, each method must either demonstrate its value and evolve into a fully-fledged solution or be discarded.

The Challenge of Scalable Solutions

As engineers, we are typically conditioned to create scalable solutions from the outset. We delve into microservices, distributed systems, and various design patterns—components essential for apps boasting millions of users. However, in a startup setting, pursuing scalable code can often result in wasted resources and time, as we engineer solutions for problems that may never materialize. By implementing my three-month rule, I am encouraged to focus on straightforward and functional code that delivers results and reveals genuine user needs.

Insights from My Current Infrastructure Enhancements

1. Consolidating Infrastructure into a Single VM

Currently, my entire stack—including the database, web server, and background jobs—operates seamlessly on a single $40/month virtual machine. This setup eliminates redundancy and involves manual backups to my local storage.

What might seem impractical has proven remarkably effective. Within two months, I gained invaluable insights into my actual resource requirements. For example, my so-called “AI-heavy” platform only peaks at 4GB of RAM. An intricate Kubernetes framework I nearly devised would have resulted in managing unused containers. Moreover, my VM’s periodic crashes have provided real-time data about failure points—often different from my original assumptions.

2. Hardcoded Configuration

Here’s a glimpse into my current configuration:

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

I’ve opted for hardcoded constants scattered throughout my codebase instead of configuration files or environment variables. This approach means that adjustments necessitate redeployment.

The advantage? I can quickly search my entire code repository for any configuration value, and each price change is cataloged in version history. In the past three months, I’ve only adjusted these values three times, saving me from the tedious process of

Leave a Reply

Your email address will not be published. Required fields are marked *