The Three-Month Framework: A Technical Approach to Embracing Unscalable Solutions
When it comes to the startup world, few pieces of advice resonate as strongly as Paul Graham’s mantra: “Do things that don’t scale.” Yet, the challenge many encounter is how to translate this wisdom into the realm of technology and coding.
After dedicating eight months to building my AI podcast platform, I’ve established a simple yet effective framework: every unscalable hack is allotted a lifespan of three months. At the end of this period, the solution must either prove its value and be developed further or be discarded entirely.
As engineers, we are conditioned to pursue scalable solutions from the very outset—design patterns, microservices, distributed systems. While these concepts are impressive and suitable for large organizations, they are often misplaced in the startup context. In fact, writing scalable code too soon can mean delaying necessary work while anticipating challenges that may never arise. My three-month rule pushes me to create straightforward, sometimes “bad,” code that ultimately leads to real shipping products and insight into user needs.
Current Infrastructure Hacks: Smart Moves in Unconventional Coding
1. One Virtual Machine for Everything
With a single $40/month virtual machine hosting my database, web server, background jobs, and Redis, I have opted for a strategy devoid of redundancy and relied on manual backups to my local machine.
What might seem reckless is actually brilliant. This approach has enabled me to better understand my resource requirements over the past two months than any formal capacity planning document could have. Surprisingly, I’ve found that my platform, which I initially deemed “AI-heavy,” only peaks at 4GB of RAM. The complicated Kubernetes setup I considered would have merely managed empty containers, and every crash (which has happened twice) provided valuable insights beyond my expectations regarding what breaks.
2. Hardcoded Configuration
Consider my approach to configuration:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no external configuration files or environment variables; just hardcoded constants sprinkled throughout the code. This means changing a parameter requires a redeployment.
The efficiency of this setup lies in accessibility—I can instantly search the entire codebase for any configuration value. Consequently, every price adjustment is documented in the git history and reviewed in the pull request process
