Embracing the Unscalable: The 3-Month Experimentation Framework for Startups

Paul Graham famously advised entrepreneurs to “do things that don’t scale,” yet few address the practical aspects of applying this wisdom to the world of coding and technology development. After eight months of constructing my AI podcast platform, I’ve devised a straightforward methodology: every makeshift, unscalable solution gets a trial period of three months. If it demonstrates its worth, it gets developed further; if not, it’s phased out.

As software engineers, we’re often conditioned to prioritize scalable solutions from the outset, focusing on intricate design patterns, microservices, and distributed frameworks designed to accommodate a vast user base. This mindset, however, aligns more closely with corporate environments than with lean startups. In many cases, pursuing a scalable approach too soon can be equivalent to delaying crucial decisions, particularly when we’re optimizing for potential users that may never materialize.

My 3-Month Rule pushes me to deploy simpler, more straightforward code that can be released quickly, allowing me to glean insights into user needs through direct experience rather than speculation.

Current Infrastructure Strategies: Why They Work

1. Consolidated Operations on a Single VM

I operate my entire backend—database, web server, background jobs, Redis—on a single virtual machine that costs just $40 per month. While this setup lacks redundancy, it has provided invaluable learning experiences. Within two months, I’ve gained a clearer understanding of my resource requirements, discovering that my platform’s peak usage hovers around 4GB of RAM. The sophisticated Kubernetes framework I nearly constructed would have involved managing unused containers.

Each crash I’ve experienced has revealed insights about system vulnerabilities, although the points of failure were often unexpected.

2. Hardcoded Configurations Across the Application

Instead of using configuration files or environment variables, I opt for hardcoded constants like this:

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

This approach enables me to quickly search my codebase for configuration values, leading to efficient version control of pricing changes. Revising any of these constants necessitates a simple redeployment, which takes only 15 minutes versus the 40 hours it would have taken to develop a configuration management service.

3. Utilizing SQLite in Production

Although SQLite is typically not used for