Embracing the 3-Month Rule: A Pragmatic Approach to Development in Startups

In the tech world, the well-known advice from Paul Graham to “do things that don’t scale” often gets tossed around, yet the practicalities of executing this in a coding environment rarely get the attention they deserve. After eight months of launching my AI podcast platform, I’ve formed a straightforward framework: any unscalable solution I implement has a lifespan of just three months. At the end of that time, it must either demonstrate its worth and be developed further or be discarded.

As engineers, we’re conditioned to focus on scalable solutions from the outset—think sophisticated design patterns, resilient microservices, and distributed systems capable of serving millions. However, this mindset is often more suited for larger organizations and can lead startups down a path of costly procrastination. By over-engineering for users yet to come or problems that may never materialize, we lose sight of our immediate needs. My three-month rule compels me to produce straightforward, albeit “less elegant,” code that can be deployed quickly and effectively. This allows me to understand what my users genuinely require.

Current Infrastructure Hacks: Smart Shortcuts to Learning

Here, I share the unorthodox approaches I’ve taken and the insights they’ve provided.

1. Consolidating Everything on a Single VM

I run my database, web server, background jobs, and caching all on a single, economical $40/month virtual machine. This comes with zero redundancy and relies on manual backups to my machine.

Why is this a wise choice rather than a reckless one? In just two months, I’ve gained a clearer understanding of my actual resource needs than any capacity planning document could provide. As it turns out, my so-called “AI-heavy” platform peaks at just 4GB of RAM. The complex Kubernetes setup I initially considered would have merely involved managing idle containers.

When the server does crash—an occurrence that has happened twice—I’ve gathered valuable insights into the real causes. Interestingly, these issues rarely align with my initial expectations.

2. Hardcoded Configuration Values

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

My configuration setup is oversimplified—constants spread throughout my codebase with no external configuration files or environment variables. Modifying any value necessitates