Embracing the 3-Month Rule: A Practical Approach to Building Scalable Solutions
In the realm of startups, there’s a commonly cited piece of advice from entrepreneur Paul Graham that encourages us to “do things that don’t scale.” While this is a valuable principle, the challenge lies in effectively applying it—particularly in the technical aspects of product development. Over the past eight months, as I’ve developed my AI podcast platform, I’ve crafted a straightforward framework grounded in this philosophy: any unscalable trick I employ has a lifespan of three months. If it proves valuable, it gets developed into a robust solution; if not, it’s time to move on.
As engineers, we’re often conditioned to prioritize scalability from day one. We gravitate towards design patterns, microservices, and highly distributed systems. While these approaches are essential for larger organizations, they can hinder startups, where the pursuit of scalability may lead to unnecessary complexity and delays. My framework advocates for simplicity—encouraging the writing of straightforward, if imperfect, code that can be quickly shipped and tested. This approach has provided me with insights into what my users genuinely need.
Current Infrastructure Hacks: A Smart Approach to Learning
1. Single-VM Architecture
I operate everything—my database, web server, background jobs, and Redis—on a single $40 monthly virtual machine (VM). While this may seem risky due to the lack of redundancy and reliance on manual backups, I’ve gained invaluable knowledge about my resource demands. In just two months, I’ve discovered that my platform experiences peak resource usage at 4GB of RAM. The overly complex Kubernetes architecture I contemplated would have been managing idle resources, and my current setup has already exposed me to real failures that are often unexpected.
2. Hardcoded Configuration
Instead of utilizing configuration files or environment variables, I have hardcoded constants throughout my codebase. For instance:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this might seem primitive, it enables efficient searching through my code for configuration values and keeps all changes neatly recorded in Git history. I’ve modified these values only three times in three months, making the minimal redeployment time far quicker than building a dedicated configuration service.
3. Using SQLite in Production
Yes, I’ve opted for SQLite for my multi-user web
