Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Tech Development
In the startup ecosystem, one piece of wisdom frequently echoed is Paul Graham’s mantra: “Do things that don’t scale.” However, the challenge often lies in knowing how to translate this guidance into actionable steps for coding and development.
After eight months of building my AI podcast platform, I’ve formulated a straightforward strategy: each unscalable hack gets a trial period of three months. At the end of this time frame, it must either demonstrate its worth and warrant a proper implementation, or it will be discarded.
The reality is that as engineers, our training often emphasizes the creation of scalable solutions from the outset. We get enveloped in design patterns, microservices, and grand architectural concepts that can support millions of users. Yet, this mindset frequently aligns more with larger corporations than startups.
At a startup, focusing on scalable code too early can lead to wasted resources. Instead of trying to accommodate hypothetical future users, my 3-month rule empowers me to produce straightforward, immediate code that can be deployed quickly, allowing me to learn about my users’ true needs.
Current Infrastructure Hacks and Their Strategic Value
1. Consolidated Infrastructure on a Single Virtual Machine
I host an array of services – including the database, web server, and background jobs – on a single $40/month VM with no redundancy and manual backups.
Here’s why this strategy is effective: I’ve gathered more actionable insights regarding my resource needs over the past two months than any extensive planning documentation could offer. Initially estimated to require an elaborate Kubernetes architecture, I’ve found that my platform’s peak resource use caps at just 4GB of RAM. Each time it crashes (which has happened twice), I receive invaluable feedback about the real causes of failure.
2. Simplistic Hardcoded Configuration
My approach includes hardcoding configuration settings, such as pricing tiers and user limits, directly in the code rather than utilizing config files or environment variables.
This methodology may sound rudimentary, but it offers several advantages: with a simple code search, I can locate any configuration value swiftly. Additionally, every configuration change is logged in my Git history. In just three months, I’ve altered these settings three times, making a quick redeployment far more efficient than developing a full-fledged configuration management service.
3. SQLite as the Production Database
Surprisingly, I utilize SQLite for my multi-user application, managing to handle
