The 3-Month Framework: A Pragmatic Approach to Imperfect Solutions

In the realm of entrepreneurship, Paul Graham’s adage—“Do things that don’t scale”—is often cited, yet seldom explored in practical terms, especially in the context of software development. After eight months of developing my AI podcast platform, I’ve established a straightforward framework that embraces this philosophy: every hack that lacks scalability is granted a lifespan of three months. At the end of this period, it’s either validated and upgraded, or it is discarded.

As developers, we are conditioned to prioritize scalable solutions from the outset—think complex architectures, microservices, and distributed systems—all engineered to accommodate millions of users. However, this big-company mindset can hinder startups where optimizing for users that don’t yet exist often leads to costly delays. My three-month rule encourages me to create simplified, less elegant code that gets deployed, providing invaluable insight into what users truly need.

Smart Hacks in My Current Infrastructure

Here are some of the strategic decisions I’ve made, alongside the rationale that underpins their effectiveness:

1. Consolidation on a Single Virtual Machine

All necessary services—from the database to the web server—are running on a single $40/month virtual machine. Yes, there’s no redundancy, and manual backups are performed to my local machine.

This approach has proven remarkably insightful; in just two months, I have gained more clarity on my resource requirements than any theoretical planning document could offer. Surprisingly, my “AI-heavy” platform only uses 4GB of RAM at peak times. Had I jumped into setting up Kubernetes, I would have been managing empty containers, rather than addressing meaningful challenges.

When the VM goes down (which has happened twice), I receive concrete data on failures—often not what I anticipated.

2. Hardcoded Configuration

Consider this structure:

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

Rather than utilizing config files or environment variables, I’ve employed hardcoded constants throughout my codebase. This means any change necessitates a redeploy.

The upside? I can swiftly search my entire code for any configuration value. Each price alteration is documented in the Git history, and I maintain control over updates—even if I’m the only reviewer. Building a dedicated configuration service would consume a week; instead, I’ve made three changes in three months