Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Tech Development

In the tech startup world, the phrase “do things that don’t scale” often surfaces, echoing Paul Graham’s famous advice. However, implementing this concept within software development isn’t always straightforward. Over the past eight months, while working on my AI podcast platform, I’ve cultivated a practical framework: every unscalable workaround gets a lifespan of just three months. After this period, it either proves its worth and gets developed properly or fades into obscurity.

As engineers, we are often trained to focus on scalable solutions from the get-go, employing advanced design patterns, microservices, and robust architectural frameworks that promise to cater to millions of users. While these techniques are essential for larger organizations, they can lead to inefficiencies in the startup environment. In many cases, crafting scalable solutions early is merely an expensive form of procrastination, as we may be optimizing for potential users who don’t yet exist.

My 3-month rule encourages me to write simple, direct, albeit “imperfect” code that ultimately impacts real users. Here’s a look at my current infrastructure hacks and the insights they provide:

1. Consolidated Operations on a Single VM

I run my database, web server, background jobs, and Redis on a single $40/month virtual machine. This setup lacks redundancy, relying on manual backups to my local system.

This unconventional choice has proven beneficial; within just two months, I’ve gained far more insight into my actual resource requirements than any capacity planning document could provide. My “AI-heavy” platform consistently peaks at 4GB of RAM—proof that a complex Kubernetes setup would have been a waste of time and energy. When crashes occur (which they have, twice), I receive invaluable data regarding failures, revealing insights I never anticipated.

2. Hardcoded Configuration

In my code, configuration values such as price tiers, maximum user limits, and AI model types are hardcoded. No need for config files or environment variables—just simple constants interspersed throughout my code files.

This approach may seem unorthodox, but it presents significant advantages. I can swiftly search my codebase for any configuration value, track changes through git history, and ensure that any modifications undergo code review procedures (albeit by myself). Instead of spending a week implementing a configuration service, I’ve spent just 15 minutes redeploying changes over the last