The 3-Month Experiment: A Pragmatic Approach to Non-Scalable Coding

In the world of startups, the mantra “Do things that don’t scale,” popularized by Paul Graham, is often quoted but seldom acted upon in the context of coding. After eight months of developing my AI podcast platform, I have developed a guiding principle around this concept: every unscalable approach gets a temporary life span of just three months. At the end of this period, each method either earns its place as a full-fledged solution or gets discarded.

As engineers, we have a natural inclination toward creating scalable solutions from the outset: designing intricate architectures with microservices, distributed systems, and sophisticated design patterns that can handle millions of users. However, this typically aligns more with large corporations than with startups, where scalable code can become an expensive form of procrastination. Often, we’re trying to optimize for user bases that are still on the horizon, tackling challenges that may never materialize. The three-month rule encourages me to produce straightforward, albeit imperfect, code that is quick to deploy and genuinely reflects user needs.

My Current Approaches: Simplicity in Action

Let’s explore some of my current infrastructure choices that may seem rudimentary but serve a strategic purpose:

1. Single VM Setup

Everything—database, web server, background jobs, and caching—runs on a single $40/month virtual machine. There’s no redundancy, and manual backups go straight to my local computer.

Why is this a smart strategy? In just two months, I’ve gained invaluable insights into my real resource needs, far more than any capacity planning document could provide. Surprisingly, my “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes setup I nearly initiated would have involved managing unnecessary containers. When crashes occur (and they have), the data reveals what genuinely goes wrong—often in ways I didn’t anticipate.

2. Hardcoded Variables

Constants like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 are embedded throughout the code without any configuration files or environment variables. Deploying changes requires performing a redeployment.

The benefits? I can quickly search my entire codebase for configuration values. Each tweak is recorded in my Git history, and while every change might get code-reviewed by me, it simplifies oversight. Spending a week building a configuration service isn’t justified when I’ve only adjusted these values thrice in three months—result