The 3-Month Experiment: A Framework for Pragmatic Development

In the world of software development, the sage advice from Paul Graham resonates: “Do things that don’t scale.” Yet, how can this principle effectively translate into your coding practices? After dedicating 8 months to building my AI podcast platform, I’ve created a straightforward model that I like to call the “3-Month Experiment.” Each unscalable hack I implement is given a life span of three months. At the end of this period, we assess whether it has proven its worth or if it’s time for it to fade away.

As engineers, we often find ourselves gravitating towards scalable solutions from the onset—crafting elaborate design patterns, microservices, and distributed systems meant for handling vast user bases. However, in the startup environment, overly focusing on scalability can lead to costly delays, optimizing for users that may not even exist yet. My 3-month framework encourages me to produce straightforward, albeit imperfect, code that facilitates real deployment and allows for genuine user insights.

My Current Infrastructure Strategies and Their Unexpected Benefits

1. Consolidated Operations on a Single VM

I run my entire operation—database, web server, background processes, and caching—on a single $40/month virtual machine. There’s no redundancy and I manually back up to my local computer.

Why is this approach effective? In just two months, I’ve gained clearer insight into my actual resource requirements than any theoretical capacity plan could provide. My platform, which I assumed was “AI-heavy,” has demonstrated peak RAM usage of only 4GB. The complex Kubernetes architecture I nearly implemented would have led me to manage empty containers instead.

When the system encounters issues, I receive tangible data about the failures, which are often unexpected.

2. Hardcoded Configurations for Simplicity

In my code, configurations look like this:

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

I avoid config files and environment variables, opting instead for constants throughout my codebase. Adjusting a parameter requires a redeployment, which might sound inefficient but has its advantages. I can swiftly search the entire codebase for configuration values using grep. Each price modification is traceable in git history, and since I’ve only adjusted these values three times in three months, the reward far outweighs