Embracing Imperfection: The 3-Month Rule for Developing Non-Scalable Solutions
In the world of entrepreneurship, advice from industry experts like Paul Graham often echoes: “Do things that don’t scale.” However, few delve into how to genuinely apply this concept within the realm of coding. After months of building my AI podcast platform, I have devised a straightforward approach: I give every hack that lacks scalability exactly three months to prove its worth. If it doesn’t demonstrate its value during that timeframe, it gets the axe.
As engineers, we are frequently conditioned to think in terms of scalable architectures from the outset—design patterns, microservices, and distributed systems all designed to accommodate millions of users. However, this thinking often aligns more with established enterprises rather than the dynamic environment of startups.
In many cases, constructing scalable solutions too early becomes a costly form of procrastination. You may find yourself optimizing for hypothetical users and preemptively addressing non-existent problems. The three-month rule compels me to develop straightforward, albeit less elegant, code that not only performs but also reveals the true needs of my users.
An Overview of My Current Infrastructure Hacks
1. Centralized Operations on a Single VM
I operate everything—from the database and web server to background jobs and caching—on a single $40/month virtual machine. This means zero redundancy and manual backups to my local system.
Why is this an astute decision? In just two months, I’ve gained insights into my actual resource requirements that no capacity planning report could provide. My “AI-centric” platform hits a peak of just 4GB RAM. The elaborate Kubernetes setup I nearly implemented would have resulted in managing wasted resources instead of real usage. When system crashes occur (and they have, twice), I obtain valuable data on what really fails—often contrary to my expectations.
2. Hardcoded Configurations
Instead of complex configuration files or environment variables, I utilize constants scattered throughout my code. This might seem primitive, but the efficiency is undeniable. I can swiftly search my entire codebase for any given configuration value. Furthermore, every change is stored in the git history and undergoes code review—albeit a personal one.
Creating a proper configuration service would demand a week of development time, while I have recalibrated these constants merely three times over the past three months. This represents just 15 minutes of redeployment compared to 40 hours of engineering work.
