The 3-Month Experiment: A Pragmatic Approach to Development

In the startup world, the advice from Paul Graham resonates with many: “Do things that don’t scale.” Yet, discussions often overlook the practical implementation of this principle in software development. After dedicating eight months to building my AI podcast platform, I’ve formulated a strategy that simplifies this philosophy: every unscalable approach is allocated a lifespan of just three months. At the end of this period, it either proves its worth and is developed further, or it is discarded.

Traditionally, software engineers are groomed to prioritize scalable solutions from the outset, focusing on elaborate design patterns, microservices, and distributed systems capable of supporting millions of users. However, this mindset often aligns more with larger corporations than agile startups. In fact, pursuing scalability too soon can lead to unnecessary costs and wasted efforts on features or infrastructure that may never be needed.

My three-month rule compels me to craft straightforward, albeit imperfect, solutions that are functional and promote an understanding of the actual needs of my users. Below, I share a few current infrastructure strategies that may seem unconventional yet are integral to my learning process.

Current Infrastructure Strategies and Their Benefits

1. Simplified Architecture on a Single VM

Currently, I operate everything — the database, web server, background jobs, and Redis — on a standalone $40/month virtual machine (VM). There’s no redundancy, and backups are done manually on my local machine.

What may seem reckless has offered valuable insights. In just two months, I’ve pinpointed my real resource needs, discovering that my “AI-heavy” platform only requires 4GB of RAM at peak usage. The complex Kubernetes setup I considered would have been overkill, not to mention managing empty containers.

When my system has crashed — which has happened twice — I’ve gained real data about actual points of failure, consistently surprising me.

2. Hardcoded Configuration Constants

I’ve opted for hardcoded config values, such as:

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

There’s no separate configuration file or environment variables; these constants vary within the code. While changing values involves redeployment, the benefit is crystal clear: I can quickly search my entire codebase for any config value. Additionally, every change is documented in