The Three-Month Rule: A Strategic Approach to Unscalable Solutions in Tech
In the world of startups, the mantra “Do things that don’t scale,” popularized by Paul Graham, is often easier said than implemented—especially when it comes to coding. After dedicating eight months to developing my AI podcast platform, I’ve established a practical framework: any unscalable solution is granted a trial period of three months. After this time, the solution either demonstrates its worth and is overhauled into a sustainable model or is discarded.
As engineers, we are conditioned to pursue scalable solutions from the onset. The allure of elegant design patterns, microservices, and expansive distributed systems is strong, but they often represent a mindset akin to that of large enterprises. In a startup environment, focusing on building scalable code can lead to unnecessary complexities—essentially a form of procrastination. You end up shaping solutions for users who aren’t even on board yet, managing issues that may never arise. My three-month rule encourages me to embrace simplicity—often resulting in what might be considered ‘bad’ code—while also ensuring that I release products that truly address user needs.
Current Infrastructure Strategies: Unconventional Yet Effective
1. Unified VM Architecture
My entire system—database, web server, background jobs, and even Redis—operates on a single $40/month virtual machine. There’s no redundancy, and I handle backups manually.
This setup has proven invaluable. Within two months, I gained insights into my actual resource demands—my AI-driven platform peaks at 4GB of RAM. The complex Kubernetes architecture I once contemplated would have been overkill, primarily managing idle resources. Each time the system crashes, which has occurred a few times, I acquire real-time data on failure points—often surprising and not what I initially anticipated.
2. Hardcoded Configuration
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Instead of conventional configuration files, I opted for hardcoded constants throughout my code. Although this may seem impractical, it allows me to search my codebase rapidly for any configuration value. Every price adjustment is documented in the git history, and all changes are subject to a review process—albeit self-imposed.
Building a dedicated configuration service would be a week-long endeavor, but I’ve only adjusted these values
