The 3-Month Horizon: A Pragmatic Approach to Non-Scalable Solutions in Tech Development

In the world of startups, the age-old advice from Paul Graham rings true: “Do things that don’t scale.” However, the implementation of this principle within a coding framework is often overlooked. As I reflect on my journey developing an AI podcast platform over the past eight months, I’ve structured my approach around a simple yet effective guideline: any non-scalable solution is given a three-month trial. After this period, it must either prove its worth and be properly constructed or be abandoned.

Rethinking Scalability

As engineers, our instinct is to design for scale right from the beginning—think microservices, intricate architecture, and frameworks that can handle millions of users. This is certainly critical for large companies, but for startups, focusing solely on scalability may be a form of costly procrastination. Too often, we end up optimizing for hypothetical users, addressing challenges that may never arise. My three-month rule encourages me to embrace straightforward and arguably “bad” code that is immediately deployable, allowing me to discover the authentic needs of my users.

Examples of My Current Infrastructure Strategies

1. Single VM Architecture

Currently, my entire tech stack—database, web server, background processes, and caching—is hosted on a single $40-per-month virtual machine. There’s no redundancy, and manual backups are stored locally.

The brilliance of this approach? I’ve gained valuable insights into my resource demands far quicker than any capacity planning spreadsheet could provide. For instance, my AI platform only needs about 4GB of RAM at peak. The complex Kubernetes setup I initially considered would have ended up overseeing countless empty containers.

Crash occurrences (yes, I’ve had two) provide real-time feedback on failure points that often surprise me.

2. Static Configurations

My code is filled with hardcoded configurations:

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

There are no separate configuration files or environment variables; each constant is directly embedded within the code, necessitating a redeployment for any change.

However, this simplifies oversight and version control. I can swiftly search my codebase to track configuration changes, which are all documented in Git history. Over the last three months, I’ve adjusted these values three times—resulting