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

In the entrepreneurial tech world, it’s common to encounter Paul Graham’s well-known advice: “Do things that don’t scale.” However, the challenge lies in successfully applying this concept within the realm of software development.

After dedicating eight months to creating my AI podcast platform, I have devised a straightforward framework: any non-scalable hack receives a three-month trial period. By the end of this timeframe, it either demonstrates its worth and is fully developed, or it is discarded.

As engineers, we often gravitate towards solutions that emphasize scalability from the outset. We immerse ourselves in designing architecture that can accommodate millions of users—think microservices, distributed systems, and intricate design patterns. Yet, this mindset is often suited for larger organizations.

For startups like mine, investing time in scalable architectures can lead to expensive delays, as we may be developing features or solving challenges for users who don’t currently exist. My 3-month rule compels me to create basic, straightforward, and seemingly less optimal code that can be released quickly, allowing me to gain insights into what users truly need.

My Ingenious Yet Simple Infrastructure Hacks

1. Consolidation on a Single VM

I have opted for a single $40/month virtual machine that hosts my database, web server, background jobs, and Redis—all without redundancy. Manual backups occur on my local machine.

This setup may seem risky, but it has been an invaluable teacher. I’ve discovered my platform requires significantly fewer resources than anticipated. For example, the architecture I almost pursued—Kubernetes—would have involved managing empty containers instead of focusing on genuine performance issues. When crashes happen (which they have), I gain real-time insights into what fails, often revealing unexpected results.

2. Hardcoded Values for Configuration Management

Configuration is managed through hardcoded constants scattered throughout my codebase, such as:

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

Although this approach lacks the sophistication of configuration files or environment variables, it allows for quick access and accountability. I can search my entire codebase for any configuration value in seconds, with each change logged in git history. Reworking a configuration service could take a week, but during the last three months, I’ve only needed to make three