The 3-Month Rule: A Pragmatic Approach to Iteration in Tech Development

In the realm of startup development, the popular adage from Paul Graham, “Do things that don’t scale,” resonates deeply. Yet, the challenge lies in translating that wisdom into actionable strategies, especially when it comes to coding.

Having dedicated 8 months to creating my AI podcast platform, I’ve formulated a distinctive framework: I give every non-scalable solution a lifespan of three months. After this period, if it demonstrates its value, I invest in building it out properly; if not, I let it go.

The startup Dilemma: The Quest for Scalable Solutions

As engineers, there’s a tendency to prioritize scalable solutions from the outset—think design patterns, microservices, and complex architectures designed for heavy traffic. While these structures are impressive, they can often lead to unnecessary complexity in a startup environment. At this stage, building for scalability can turn into a form of procrastination, where time is spent optimizing for future users rather than addressing immediate needs.

My three-month rule encourages me to produce straightforward, albeit less refined, code that can be deployed swiftly. This approach sheds light on what users genuinely require.

Current Infrastructure Practices: A Surprising Success

1. Consolidated on a Single Virtual Machine

All components—database, web server, background tasks, and caching—operate on one $40/month VM. There’s no redundancy, and backups are conducted manually.

This approach has yielded valuable insights into my resource needs in just two months, far surpassing what any formal capacity planning could achieve. For instance, my platform’s peak usage has been a mere 4GB of RAM; had I opted for a complex Kubernetes setup, I would have been managing resources that didn’t need managing. Each crash provides concrete data about failures, often revealing unexpected bottlenecks.

2. Hardcoded Configuration

In my code, important constants like pricing and user limits are hardcoded.

Though this may seem impractical, it allows me to track all changes in my version control history quickly. I’ve made only three adjustments to these values in three months, translating to mere minutes of redeployment versus the many hours that could have been spent on a configuration service.

3. SQLite in Production for Multi-User Application

I’m utilizing SQLite for my application’s database, which has a modest 47MB footprint and smoothly accommodates 50 simultaneous users.

This revelation came from analyzing usage patterns;