Embracing the 3-Month Rule: A Pragmatic Approach to Software Development
In the world of technology and entrepreneurship, one piece of advice stands out: “Do things that don’t scale,” as famously articulated by Paul Graham. Yet, the challenge lies in effectively implementing this mindset, especially in software development. After eight months of building my AI podcast platform, I’ve established a straightforward yet powerful framework: any unscalable solution I employ will be given three months to prove its worth. After this period, it either transitions into a robust, scalable version or gets phased out.
As engineers, we often gravitate towards building scalable solutions right from the outset. We admire the beauty of intricate architectures like microservices and distributed systems designed to accommodate millions of users. However, this approach is more suited for established companies than startups. In a startup environment, focusing too early on scalability can lead to inefficiencies, as we’re often optimizing for users who haven’t yet materialized and problems that may never arise. By adhering to my 3-month rule, I prioritize writing simple, effective code that quickly delivers insights into user needs.
Innovative Infrastructure Hacks: My Current Practices
Let’s take a closer look at some unconventional infrastructure decisions I’ve made, each with its own rationale for why they make sense:
1. All-In-One Virtual Machine
I run everything—web server, database, background jobs, and caching—on a single $40/month virtual machine. While this setup lacks redundancy and depends on manual backups, it has provided invaluable insights into my actual resource requirements. Surprisingly, my AI platform only peaks at 4GB of RAM. The complex Kubernetes configuration I nearly implemented would have involved managing idle containers instead. Each time the system crashes (which has happened twice), I gain real data on what failures occur, revealing truths I’d never anticipated.
2. Hardcoded Configuration
Instead of utilizing configuration files or environment variables, I’ve opted for hardcoded constants throughout my code. This approach means that any changes require a redeployment, yet it allows me to quickly search my entire codebase for values. Each price adjustment is documented in git history and undergoes a review process, albeit self-administered. Building a dedicated configuration service would have taken at least a week, but given that I’ve changed these values three times in three months, I consider this a worthwhile trade-off: 15 minutes of redeployment versus 40 hours of engineering effort.
