Embracing Temporary Solutions: The 3-Month Rule for Unscalable Innovation
In the tech startup landscape, there’s a well-known piece of advice attributed to Paul Graham: “Do things that don’t scale.” However, the challenge lies in understanding how to effectively incorporate this principle into your coding practices.
After dedicating eight months to building my AI podcast platform, I developed a straightforward method: every unscalable workaround has a three-month lifespan. At the end of this period, it either demonstrates its worth and transitions into a sustainable solution or it’s discarded.
As software engineers, we often feel inclined to create scalable solutions from the outset—design patterns, microservices, distributed systems—an architectural dream meant for vast audiences. Yet, in a startup, aiming for immediate scalability can lead to unnecessary financial strain, as it focuses on hypothetical user bases and unresolved challenges. My three-month rule compels me to write straightforward, even “suboptimal” code that makes it to production and reveals actual user needs.
Current Unorthodox Practices and Their Benefits
1. Consolidated Operations on a Single VM
I’m currently running all my application components—database, web server, background jobs, and Redis—on a single $40/month virtual machine (VM), with no redundancy and manual backups to my local storage.
This approach might seem reckless initially, but it has allowed me to gauge my actual resource needs far better than any planned capacity document could. Surprisingly, my supposedly resource-intensive application only requires 4GB of RAM. The high-complexity Kubernetes setup I nearly implemented would have resulted in wasted resources, managing idle containers. Each time the system crashes (which has occurred twice so far), I gain insight into what truly fails—surprisingly, it’s never what I anticipated.
2. Hardcoded Configurations
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
With hardcoded constants in my code, I bypass the complications of config files and environment variables. Adjusting values means redeployment, but this simplicity allows for rapid navigation of my codebase. Every pricing update is logged in Git history, and each modification undergoes a code review—albeit by me.
Implementing a configuration service would take a week, but I’ve changed these values just three times in three months, translating
