Embracing the 3-Month Rule: A Practical Approach to Unscalable Engineering
In the tech world, Paul GrahamΓÇÖs concept of doing things that donΓÇÖt scale is well-known, yet the implementation of this principle in coding practices is often overlooked. After eight months of developing my AI podcast platform, IΓÇÖve established a straightforward framework that I call the ΓÇ£3-Month Rule.ΓÇ¥ This guideline dictates that every unscalable hack I employ has a lifespan of three months. At the end of this period, each solution is evaluated for its effectiveness: it either gets refined into a robust system or is discarded.
As engineers, we are often encouraged to create scalable solutions from the outset, with a strong emphasis on design patterns and architectures capable of supporting millions of users. However, this approach typically aligns more with large organizations than with startups, where pursuing scalable code often results in unnecessary delays. By committing to my 3-month rule, I focus on writing straightforward, albeit less-than-ideal code that is functional and helps me gather valuable insights into user needs.
Current Infrastructure Workarounds: Why They Make Sense
1. Consolidated Infrastructure on a Single VM
IΓÇÖm running my entire stackΓÇödatabase, web server, background jobs, and cachingΓÇöon a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, itΓÇÖs offered me crucial insights into my resource usage. Within two months, I learned that my platform usually operates with just 4GB of RAM, which likely would have been lost amidst a complex Kubernetes architecture. Each crash has provided real data about system vulnerabilitiesΓÇöinformation I would have otherwise misjudged.
2. Directly Hardcoded Configurations
Throughout my codebase, configurations like pricing tiers and user limits are hardcoded as constants. Although this means any change requires redeployment, it allows for swift searches across files and simplifies tracking in version control. Over three months, I made precisely three updatesΓÇöspending a mere 15 minutes redeploying instead of investing countless hours to build a separate configuration service.
3. Using SQLite for Production
Yes, my multi-user web application operates on SQLite, with a tiny database size of just 47MB that efficiently supports 50 concurrent users. This decision stemmed from identifying that 95% of my access patterns were read operations, which SQLite handles adeptly. Had I opted for a more complex system like Postgres, I could have wasted energy on
2 Comments
This is a refreshing perspective that highlights the importance of pragmatism and speed in early-stage engineering, especially within startups. The 3-Month Rule neatly encapsulates the idea that initial solutions should prioritize learning and rapid iteration over perfection or scalabilityΓÇöallowing product teams to validate assumptions before investing heavily in infrastructure. I find particularly insightful your approach of using simple setups like a single VM and SQLite to gain real-world insights without overcommitting resources.
It’s worth noting that embracing unscalable hacks temporarily can also lead to clearer understanding of user behavior and system bottlenecks, which are crucial when designing more scalable solutions later. The key, as you rightly emphasize, is to systematically evaluate these setups every three months and refine or abandon them accordingly. This disciplined approach prevents technical debt accumulation while maintaining agility, especially important in the dynamic environment of startups. Thanks for sharing this practical framework╬ô├ç├╢it’s a valuable addition to the ongoing conversation about balancing speed, simplicity, and future-proofing in engineering.
This post offers a compelling perspective on balancing speed and strategic planning in early-stage development. The ╬ô├ç┬ú3-Month Rule╬ô├ç┬Ñ echoes some classic lean startup principles╬ô├ç├╢prioritizing rapid iteration to validate assumptions before investing in scalable infrastructure. It╬ô├ç├ûs interesting how the author leverages simple, sometimes “unscalable” solutions like a single VM, hardcoded configs, and SQLite to gain rapid feedback while maintaining agility.
From an engineering standpoint, this approach aligns with minimizing cognitive load and avoiding premature optimizationΓÇöa common pitfall. Focusing on a manageable, low-cost infrastructure allows for faster learning and resource allocation based on real data rather than assumptions. It also reminds me of the importance of ΓÇ£technical debtΓÇ¥ as a tool rather than an obstacle; intentionally incurring some debt for short-term gain, then actively managing it, can accelerate product-market fit.
Ultimately, the key takeaway is that initial unscalable hacks, when time-boxed and thoughtfully evaluated, provide invaluable insights that inform more robust, scalable solutions. ItΓÇÖs about being pragmatic, iterative, and mindful of when to pivot or refactor as the product and user base evolve.