The 3-Month Experiment: A Pragmatic Approach to Building for Tomorrow

In the startup world, you often hear advice akin to Paul Graham’s mantra: “Do things that don’t scale.” However, the conversation rarely dives into the actionable strategies for implementing this in the realm of coding and software development. After spending eight months on my AI podcast platform, I’ve devised a straightforward framework that I call the 3-Month Rule. Essentially, any hack or unscalable solution I implement gets a three-month trial period. If it proves its worth, I refine it into a fully-fledged feature. If not, it’s time to let it go.

Challenging the Norm: Why startups Need a Different Approach

As engineers, our instinct is often to craft scalable solutions right from the start. We get caught up in the intricate designs of microservices and distributed systems, conjuring architectures suited for companies with millions of users. This, however, can lead to heightened expenses and unnecessary complexity, especially for startups still finding their footing.

In many cases, writing scalable code early becomes a form of procrastination, focusing on users that don’t yet exist. My 3-Month Rule compels me to embrace simpler, more direct code that delivers value and provides clarity on what my users genuinely need.

Current Strategies: Unconventional Yet Enlightening

Here’s a closer look at some of my current infrastructure hacks and the insights gained from them:

1. Consolidation on a Single VM

I’ve isolated everything – database, web server, background jobs, and Redis – on a single $40/month virtual machine, with no redundancy and manual backups to my local machine. Surprisingly, this setup has been a treasure trove of learning. Within just two months, I gained a clearer understanding of my resource needs—discovering that my “AI-heavy” platform only peaks at 4GB of RAM. The complex Kubernetes architecture I nearly deployed would have led to managing empty containers.

When the system crashes (and it has twice), I receive real-time insights into the root cause of the issue—often revealing surprises.

2. Hardcoded Configurations Throughout

Any constants in my code, whether pricing tiers or user limits, are hardcoded. While this might seem counterintuitive, it brings efficiency. A quick search of the entire codebase allows me to track changes seamlessly. Over the past three months, I’ve modified these hardcoded values a mere three times, transitioning