Embracing the 3-Month Rule: A Practical Approach for Startups

In the ever-evolving world of technology, we often hear the mantra from Paul Graham: “Do things that don’t scale.” While this advice is prevalent, the conversation rarely delves into the practicalities of applying it within the realm of software development. Over the past eight months, while building my AI podcast platform, I’ve established a straightforward framework: any non-scalable solution is given a trial period of three months. At the end of this period, it either demonstrates its worth and is further developed, or it’s phased out for good.

As engineers, we’re conditioned to prioritize scalable solutions from the outset. We immerse ourselves in design patterns, microservices, and architectures that can accommodate millions of users. However, this mindset is often more suited to larger corporations with established user bases. For startups, on the other hand, this inclination towards scalability can lead to costly delays and wasted resources.

The aim of my three-month rule is to encourage the development of simpler, more direct solutions—what some might deem “bad” code—that actually push us forward, revealing the real needs of our users.

My Current Approach to Infrastructure and its Benefits

1. Consolidated Resources on One Virtual Machine

By running everything—from the database to the web server—on a single $40/month virtual machine, I’ve eliminated redundancy and opted for manual backups to my local machine.

This approach has yielded profound insights into my resource requirements, far surpassing what any typical capacity planning document could provide. Surprisingly, my AI-centric platform has peaks of just 4GB of RAM. The complex Kubernetes infrastructure I considered would have resulted in managing unused containers instead of addressing real operational needs.

When outages occur (and they have), I gain invaluable data on actual system failures—often surprising insights into what truly breaks.

2. Simplified Configuration Management

Instead of using dynamic configuration files, I utilize hardcoded constants scattered throughout my code.

For example:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This method might appear rudimentary, but it possesses a hidden advantage: I can quickly search my entire codebase for any configuration value. Each change is easily tracked in my git history, ensuring accountability. Given that I’ve only changed these values a few