Embracing the 3-Month Rule: A Practical Approach to Building Unscalable Solutions in Tech

In the world of technology, you’ll often come across the famous advice from Paul Graham: “Do things that don’t scale.” While this mantra is widely acknowledged, the challenge lies in putting it into practice, particularly in coding.

After dedicating eight months to developing my AI podcast platform, I’ve established a straightforward approach: every non-scalable hack I employ is granted a lifespan of just three months. Following this period, I assess its value: if it proves effective, it gets the investment it needs for a solid build; otherwise, it gets discontinued.

As software engineers, our training often propels us toward creating scalable solutions from the outset. We find ourselves immersed in the world of design patterns, microservices, and sophisticated architectures meant to accommodate millions of users. However, such big-company thinking may not suit the startup environment.

At a startup, focusing excessively on scalability can lead to costly distractions. You might optimize for factors that have not yet materialized, addressing challenges that might never arise. The 3-month rule encourages me to produce straightforward, albeit rudimentary code that is promptly deployed, offering real insights into user needs.

Innovative Yet Practical Infrastructure Hacks

1. Consolidating Resources on One VM

Currently, I host my database, web server, background jobs, and Redis—all on a single $40 monthly virtual machine (VM). While there’s no redundancy and backups are manually conducted, this strategy has proven enlightening.

In just two months, I gained deeper insight into my resource requirements than any capacity planning document could provide. For instance, my “AI-intensive” platform only requires 4GB of RAM at peak usage. The intricate Kubernetes setup I nearly implemented would have resulted in empty containers needing management.

When issues arise, which they have twice, the crash reveals invaluable data about the underlying problems—often not what I anticipated.

2. Using Hardcoded Configurations

Instead of dedicating time to configuration files or environment variables, I use hardcoded constants throughout my codebase, such as:

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

While it may seem impractical, this method grants me rapid access to search any configuration value across my entire project. Changes are logged in git, and any configuration update undergo