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

In the realm of startup culture, one piece of wisdom frequently cited is Paul Graham’s mantra: “Do things that don’t scale.” Yet, while this advice is widely acknowledged, the practical implementation of it in the world of coding often goes unexplored.

Over the past eight months, as I’ve been developing my AI-focused podcast platform, I’ve formulated a straightforward yet powerful framework: each unscalable solution I implement is given a lifespan of precisely three months. After this period, it’s either validated and evolved into a robust feature, or it’s phased out entirely.

Rethinking Scalability in Startups

As engineers, we’re conditioned to prioritize scalable solutions from the outset—think design patterns, microservices, and distributed systems. While these approaches are indeed effective for larger enterprises handling millions of users, they often become a hindrance in a startup environment.

In a startup setting, investing time in scalable architecture early on can result in costly delays. By focusing on potential users who may or may not materialize, we risk wasting resources addressing problems that aren’t relevant yet. My three-month rule encourages me to produce straightforward, even rudimentary code that can be deployed quickly, allowing me to learn firsthand what my users actually need.

Current Hacks in My Infrastructure

Here’s a snapshot of my current infrastructural quirks and the pragmatic reasoning behind them:

1. Consolidated Operations on a Single VM

With my database, web server, background jobs, and caching all running on a single $40/month virtual machine, I consciously forego redundancy and perform manual backups to my local environment. This may seem reckless, but it’s provided invaluable insights into my actual usage patterns. After monitoring resource allocation for two months, I’ve discerned that my platform’s peak usage is just 4GB of RAM. The complex Kubernetes setup that I almost implemented would have been managing empty resources instead of functional workloads. When crashes occur—which they have, twice—I gain real-time understanding of the root causes, which tend to differ from my initial expectations.

2. Directly Hardcoded Configuration

I maintain hardcoded configurations throughout my codebase:

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

With no reliance on config files or environment