Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Coding

In the world of startups, the conventional wisdom often leans towards the mantra “Do things that don’t scale,” as famously suggested by Paul Graham. However, the conversation rarely delves into the practical application of this advice within the realm of software development. After eight months of crafting my AI podcast platform, I’ve established a straightforward methodology: every unscalable solution is bound by a 3-month lifespan. At the end of this period, it either proves its worth and transitions into a scalable solution or is abandoned altogether.

As engineers, we’ve been conditioned to design for scalability from the outset—think along the lines of intricate architecture, microservices, and distributed systems, all aimed at accommodating millions of users. This mindset, however, is often suited for larger enterprises rather than the nimble startup landscape. Within the startup context, striving for immediately scalable solutions can equate to costly procrastination, as we overly optimize for potential users that may never materialize. My 3-month rule encourages me to write straightforward, albeit imperfect, code that gets deployed and provides invaluable insights into user behavior.

Insights from My Current Infrastructure and Why They Work

1. Consolidation on a Single Virtual Machine

Currently, my entire infrastructure—database, web server, background jobs, Redis—resides on a single $40/month virtual machine with no redundancy and manual backups to my local system.

This approach has its merits: over the last two months, I’ve gained a clearer understanding of my actual resource requirements, far beyond what any capacity planning document could reveal. For instance, my “AI-heavy” platform peaks at just 4GB of RAM. The complex Kubernetes architecture I nearly put in place would only have been managing empty containers.

When my setup has crashed—twice, to date—I’ve gleaned real-world insights into what fails. Contrary to my assumptions, it was never what I expected.

2. Hardcoded Configuration

My current codebase features constants scattered throughout rather than relying on config files or environment variables:

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

While this might appear primitive, it grants me quick access to configuration values across the entire codebase. Each change requires a simple redeployment, and I can