The Three-Month Experiment: An Effective Framework for Building Non-Scalable Solutions

In the tech world, there’s a well-known piece of advice from Paul Graham: “Do things that don’t scale.” While many people agree with this principle, the challenge lies in its practical application, especially in software development. After eight months of developing my AI podcast platform, I’ve adopted a straightforward yet effective framework: I allow every unscalable hack a lifespan of just three months. At the end of that period, each hack either proves its worth and gets refined into a robust solution, or it gets terminated.

As software engineers, we’re often conditioned to create solutions designed for scale from the outset. We focus on intricate design patterns, microservices, and distributed systems—architectures aimed at accommodating millions of users. However, that mindset is typically suited for larger enterprises.

In a startup environment, chasing scalability too early can lead to costly delays. You may find yourself optimizing for a user base that doesn’t exist yet and addressing issues that may never arise. My three-month rule encourages me to implement straightforward, sometimes suboptimal, code that actually gets deployed, giving me crucial insights into what users genuinely need.

Current Infrastructure Hacks: Smart Solutions in Disguise

1. Single VM Deployment

I’ve opted to run my entire infrastructure—database, web server, background processing, Redis—on a single $40-per-month virtual machine without redundancy. While it may seem reckless, this decision has rapidly clarified my resource requirements. In just two months, I learned my platform peaks at 4GB of RAM. The complex Kubernetes setup I almost built would have been managing resources that were never utilized.

When things go wrong (and they have, twice), I gain invaluable data about actual failure points, which tend to be surprising and not what I anticipated.

2. Hardcoded Configuration

Instead of utilizing configuration files or environment variables, I keep constants directly in the code:

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

While this may seem primitive, it offers a hidden advantage: I can quickly search my entire codebase for any configuration value. Changes are easily tracked in my Git history, with each adjustment subjected to a code review—by me, no less.

Creating a centralized configuration service might take a week of development. In the past three