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

In the startup world, the conventional wisdom often revolves around the idea of “doing things that don’t scale,” as famously stated by Paul Graham. However, the conversation seldom touches on the practical strategies for implementing this philosophy in the realm of software development.

Having dedicated the last eight months to constructing my AI podcast platform, I’ve adopted a straightforward framework: every hack that isn’t scalable receives a trial period of three months. After this timeframe, each strategy will either demonstrate its worth and be expanded upon or be discarded entirely.

The Challenge with Traditional Development Mindsets

As engineers, we’re groomed to design systems that are scalable from the outset. We immerse ourselves in advanced architecture concepts such as design patterns, microservices, and distributed systems, all aimed at accommodating vast numbers of users. While this mindset is valuable for larger enterprises, startups often face a paradox: investing time in scalable solutions early on can feel like an expensive form of procrastination.

In my experience, it’s more beneficial to focus on writing straightforward, even “suboptimal” code that can be deployed quickly and enables me to gather insights about users’ real needs.

My Unconventional Infrastructure Techniques

Here are a few of my current non-scalable hacks and the rationales behind their effectiveness:

1. Consolidating Everything on a Single VM

I run my entire infrastructure—a database, web server, background jobs, and Redis—all from one $40/month virtual machine. Although it lacks redundancy and relies on manual local backups, this setup has rapidly informed me about my resource requirements. The over-engineered solutions I once considered, like Kubernetes, would have ended up being wasteful. By experiencing crashes firsthand, I’ve gained candid insights into my system’s weak points.

2. Simplistic Hardcoded Configurations

Instead of using configuration files or environment variables, I have constants defined throughout my codebase, such as pricing tiers and user limits. This approach allows me to make rapid changes and see a clear change history through Git. Over the past three months, I’ve made minimal alterations—spending just a fraction of the time I would have invested in creating a more complex config service.

3. Utilizing SQLite in Production

Surprisingly, my application runs smoothly on SQLite, handling up to 50 concurrent users effortlessly. This choice has uncovered that my data access patterns are predominantly reads, making SQLite a