Embracing the 3-Month Rule: A Pragmatic Approach to Building Scalable Software in Startups

In the world of technology, especially at startups, adhering to Paul Graham’s sage advice to “do things that don’t scale” can often lead to miraculous breakthroughs. Yet, the challenge lies in effectively implementing this concept in our coding practices.

For the past eight months, I have been developing my AI podcast platform and have devised a straightforward framework to guide my process: every unscalable hack is given a lifespan of just three months. After this period, each hack must either prove its value to warrant further investment or be discarded.

As engineers, we are often conditioned to build scalable solutions right from the outset. We become enamored with architectural elegance—think design patterns, microservices, and robust distributed systems, all aimed at accommodating millions of users. However, this mindset often aligns more with the goals of larger companies than with the nimble essence of a startup.

In the context of a startup, focusing excessively on scalability can lead to costly delays, as we tend to optimize for potential users who may never materialize while solving problems that may not exist yet. My 3-month rule compels me to write simpler, more direct code, allowing me to ship quickly and genuinely discover what users need.

Smart Infrastructure Hacks: A Closer Look

1. One Virtual Machine for All

I’ve centralized the database, web server, background jobs, and Redis on a single $40/month virtual machine. This setup, devoid of redundancy and featuring manual backups to my local machine, has proven insightful.

In just two months, I gained more understanding of my resource requirements than any theoretical capacity planning document could offer. Surprisingly, my platform’s peak demand was only 4GB of RAM. The complex Kubernetes architecture I almost implemented would have wasted time managing empty resources. When the server experiences crashes—and it has—every incident provides valuable lessons about actual vulnerabilities.

2. Hardcoded Configurations

In my code, various configurations are hardcoded as constants:

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

There are no configuration files or environment variables—just simple constants. Though changing these configurations requires a redeployment, this approach enables me to quickly search the entire codebase for any value. I can track