Embracing the 3-Month Rule: A Strategic Approach to Non-Scalable Solutions
In the startup landscape, one piece of wisdom often echoes from the halls of Paul Graham: “Do things that don’t scale.” While this advice resonates, implementing it effectively in a technical environment, particularly when coding, remains a challenge that is seldom addressed.
After eight months of developing my AI podcast platform, I’ve crafted a straightforward yet powerful framework that revolves around a simple tenet: every non-scalable solution receives a lifespan of three months. At the end of this period, solutions must either demonstrate their value and evolve into robust implementations or be phased out.
The reality for engineers is that we often feel pressured to create scalable systems from the outset. We tend to prioritize intricate design patterns, microservices, and distributed systems that compete with the best out there—ideal for companies with massive user bases. However, this type of thinking may not serve a startup’s immediate needs, where scalable code can turn into an expensive form of procrastination, optimizing for hypothetical users rather than focusing on current realities.
By adhering to my 3-month rule, I’m encouraged to write straightforward, albeit imperfect, code that gets deployed. This approach not only leads to product delivery but also reveals practical insights about user requirements.
Current Strategies and Their Merits
1. Unified VM Deployment
My entire platform operates from a single virtual machine (VM), which houses the database, web server, background jobs, and Redis—all for just $40 a month. This setup sacrifices redundancy and relies on manual backups to my local machine.
Why is this approach advantageous? In just two months, I’ve gained more insight into my actual resource needs than any capacity-planning document could provide. It turns out that my “AI-focused” platform rarely uses more than 4GB of RAM. The complex Kubernetes architecture I nearly adopted would have been overkill, wasting resources on managing empty containers. Each time the system crashes—an occurrence I have experienced twice—I receive valuable data on the actual points of failure, often surprising me.
2. Straightforward Hardcoded Configurations
I’ve chosen to embed configuration parameters directly within the code, such as:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This practice eschews configuration files or environment variables. While it requires
