The 3-Month Experimentation Rule: A Framework for Building Unscalable Solutions

In the startup world, where efficiency often clashes with idealism, Paul Graham’s famous maxim to “do things that don’t scale” is frequently quoted but rarely unpacked—especially in the realm of software development. After eight months of building my AI podcast platform, I’ve devised a straightforward strategy: every unscalable quick fix has a lifespan of just three months. Within this timeframe, it must either demonstrate its worth and evolve into a robust solution, or it will be discarded.

As developers, our instinct is to engineer scalable solutions from the outset. We tend to gravitate toward complex architectures—design patterns, microservices, and distributed systems—that promise to accommodate millions of users. However, this mindset is often more suited to established companies than scrappy startups. Focusing too heavily on scalability can lead to costly delays, as we end up optimizing for future users who may never materialize. My 3-month rule encourages me to write simpler, more direct code—what some might label as “bad” code—that ultimately delivers real insights about user needs.

My Practical Infrastructure Hacks: Why They Work

1. Consolidating Services on a Single VM

I’ve opted to run everything—from the database to background jobs—on a single $40/month virtual machine. Although it lacks redundancy and relies on manual backups to my local machine, this approach has been surprisingly enlightening.

In just two months, I’ve gained more insight into my resource usage than with any capacity planning exercise. My platform’s demands peaked at 4GB of RAM, making the complex Kubernetes infrastructure I initially considered unnecessary. When my system crashes—something that has happened twice—I gather invaluable data about unexpected points of failure.

2. Hardcoded Configuration for Speed

I’ve chosen to hardcode configuration values directly into my codebase. Variables like price tiers and user caps are defined as constants scattered throughout my files.

While this might seem inefficient at first glance, it allows me to quickly search for any configuration value. Changes are infrequent—only three in the last three months—so the time spent redeploying them is minimal compared to the extensive hours that building a separate configuration service would entail.

3. Utilizing SQLite in Production

For my multi-user application, I’m using SQLite, which has proven reliable even as my database has grown to 47MB. It can smoothly handle up to 50 concurrent users, which