The Three-Month Experiment: A Practical Approach to Building Solutions That Don’t Scale

In the world of startups, the mantra “Do things that don’t scale,” popularized by entrepreneur Paul Graham, is often tossed around. However, it’s surprising how little guidance there is on actively applying this concept within the realm of software development. Over the past eight months, while working on my AI podcast platform, I’ve adopted a framework that has drastically shifted my approach to coding.

My Three-Month Rule

My strategy is straightforward: every hack or workaround that is inherently unscalable is given a lifespan of three months. After this period, each hack must either demonstrate its usefulness and be developed into a scalable solution or be discarded entirely.

As engineers, we have been conditioned to think about scalability from the outset. We often envision complex architectures—microservices, distributed systems, and intricate design patterns—suitable for handling millions of users. But in a startup environment, focusing on scalability too soon can lead to unnecessary complications and wasted resources, as we may end up optimizing for hypotheticals rather than real user data.

Learning Through Simplicity: My Current Infrastructure Hacks

1. Consolidating on One Virtual Machine

All components of my application—database, web server, background processing, and caching—run on a single $40/month virtual machine (VM) with no redundancy and manual backups to my local machine.

Why is this a smart move? In just two months, I’ve gained invaluable insights into my resource needs that any capacity planning document could not provide. As it turns out, my application doesn’t require the elaborate infrastructure I initially envisioned; it peaks at a mere 4GB of RAM. Instead of managing empty containers, I’m getting real-time data about what causes crashes, which—surprisingly—has never been what I anticipated.

2. Hardcoding Configuration Values

Throughout my code, you’ll find constants such as:

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

There are no config files or environment variables involved—just constants across various files. This choice does come with trade-offs, but the benefit is significant. I can efficiently search my entire codebase for any configuration value within seconds, and any changes are tracked in git history. My workflow has been streamlined; modifications have occurred only three