Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech Development
In the world of startups and tech innovation, the mantra often recited is Paul Graham’s famous advice to “do things that don’t scale.” However, the challenge lies in translating this conceptual guidance into actionable steps within the realm of software development. As a result of eight months of building an AI podcast platform, I’ve developed a straightforward framework: each unscalable solution is given a lifespan of three months. After this period, it must either demonstrate its worth and be properly implemented or be discarded.
The reality is that as engineers, we are often conditioned to focus on scalable solutions from the get-go. We’re drawn to sleek design patterns and sophisticated architectures, aimed at accommodating millions of users. This mindset suits larger organizations but often proves ineffective in a startup setting, where the pursuit of scalability can delay urgent action while optimizing for users who may not even exist yet. My three-month rule encourages me to create straightforward, sometimes “imperfect,” code that actually gets deployed and reveals critical insights about user behavior and needs.
Current Infrastructure Strategies: Why They’re Smart Moves
1. Consolidated Resources on One Virtual Machine
All essential services—database, web server, background jobs, and caching—run on a single $40/month virtual machine. While this setup lacks redundancy and dependency management, it teaches invaluable lessons. In just two months, I’ve gained insights about resource requirements that could never be captured in theoretical planning documents. My platform, which is ostensibly resource-heavy, only peaks at 4GB of RAM. Instead of managing complex Kubernetes clusters, I gather real-time information about performance issues whenever the system crashes, which, surprisingly, has not aligned with my assumptions.
2. Hardcoded Values Across the Codebase
Using hardcoded constants for configurations, such as pricing tiers and user limits, means no configuration files or environment variables are involved. While this may seem inefficient, it allows me to quickly locate any configuration value across the entire codebase. Changing parameters means redeploying, which I’ve done sparingly—just three times in three months. The time spent redeploying is a fraction of what building a sophisticated configuration management system would require, providing a pragmatic balance of time and learning.
3. SQLite as a Production Database
I’ve chosen to run SQLite for a web application with multiple users, and the database size sits at a mere 47MB
