The 3-Month Rule: A Practical Approach to Building Non-Scalable Solutions

In the world of startups and tech entrepreneurship, the wisdom of industry leaders often serves as a guiding light. One such piece of advice comes from Paul Graham: “Do things that don’t scale.” While this maxim resonates with many, the practical application of it in the realm of software development often goes unspoken.

Having worked on my AI podcast platform for the past eight months, I’ve adopted a straightforward framework that I call the “3-Month Rule.” In essence, any non-scalable solution I implement is given a trial period of three months. After this time, it either demonstrates its value and is rebuilt for scalability, or it is phased out entirely.

As engineers, we typically focus on crafting scalable architectures from the get-go—think design patterns, microservices, and distributed systems designed to accommodate millions of users. However, this mindset is often more suited to established corporations than to startups. In the early stages, investing time to develop scalable code can lead to unnecessary delays, optimizing for an audience that may not even exist yet. My 3-Month Rule compels me to write straightforward, albeit imperfect, code that can be deployed quickly, revealing the genuine needs of my users.

Current Infrastructure Strategies: Insights Beyond the Surface

1. Centralized VM Hosting

My entire application—database, web server, background processing, and Redis—runs on a single virtual machine that costs only $40 per month. While it lacks redundancy and relies on manual backups to my local machine, this setup has proven invaluable. In just two months, I’ve gained invaluable insights into my resource requirements far beyond what any theoretical capacity planning could offer. It turns out, my “AI-focused” platform peaks at just 4GB of RAM. The complex Kubernetes architecture I almost implemented would have been wasted on managing idle containers. Each time the system crashes (which has happened a couple of times), I gather concrete data about the actual points of failure—often surprising me.

2. Hardcoded Configuration Values

Instead of separate configuration files and environment variables, I use hardcoded constants throughout my codebase:

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

While it may seem unorthodox, this approach allows me to quickly search for and track changes