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

In the world of startups, a common piece of wisdom often touted is Paul Graham’s mantra: “Do things that don’t scale.” While many acknowledge the importance of this concept, few delve into its practical application within the coding sphere.

Over the past eight months while developing my AI podcast platform, I’ve adopted a straightforward framework. Each non-scalable workaround I implement is allocated a maximum lifespan of three months. After this period, solutions are either fortified based on the value they demonstrated or phased out.

The start-up Mindset: Prioritizing Lean Development

As engineers, we are frequently trained to devise solutions that are scalable from the outset—envisioning architectures like microservices and distributed systems ready to support millions of users. However, as a startup, this approach can lead to unnecessary complexity. Focusing on scalability too early can turn into a costly postponement of critical learning. My 3-month rule challenges this notion by requiring me to produce straightforward, perhaps “imperfect,” code that delivers real insights into user needs.

Current Simplified Infrastructure Hacks

Here’s a look at my unorthodox practices and the practical wisdom I’ve gained through them:

1. Single VM Deployment

I have consolidated my database, web server, and background jobs onto a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, it has provided invaluable insights into my actual resource requirements. After two months of operation, I’ve discovered that my AI-focused platform peaks at just 4GB of RAM. The complicated Kubernetes infrastructure I almost built would have simply been managing idle containers. Each crash—two thus far—has offered real data on failure points, none of which were on my radar.

2. Hardcoded Configurations

In my code, configuration settings, such as pricing tiers and user limits, are directly embedded, with no separate config files or environment variables. While some might view this as a drawback, it has proven to be a strength. I can quickly search through my entire codebase for config values, maintaining a clear git history for any changes. In just three months, I’ve adjusted these values a mere three times, saving significant developmental hours in favor of efficiency.

3. Utilizing SQLite in Production

Yes, I’m using SQLite for a web app that supports multiple users. With a total database size of just 47MB, it effortlessly caters to 50 concurrent users