Embracing the 3-Month Rule: A Refreshing Approach to Unscalable Solutions in Tech
When it comes to the world of startups, the advice from Paul Graham sticks: “Do things that don’t scale.” Yet, practical strategies for applying this philosophy within the realm of coding often go unaddressed.
After eight months of developing my AI podcast platform, I’ve stumbled upon a valuable guideline: every unscalable approach gets a trial period of three months. At the end of this span, it must either prove its worth and be properly refined or be discarded.
The startup Mindset: Rethinking Scalability
As engineers, we often gravitate towards creating scalable solutions right from the outset. Concepts like design patterns, microservices, and distributed systems dominate our thinking, particularly for those working in larger organizations. However, at a startup, pursuing scalable code too early can lead to inefficiencies and result in wasted resources. My three-month rule encourages an agile mindset—allowing me to write straightforward, albeit ‘suboptimal,’ code that enables me to quickly assess user needs.
Clever Infrastructure Hacks That Yield Insights
1. Consolidation on a Single Virtual Machine
Everything from the database to the web server is running on a single $40-a-month virtual machine. While there’s no redundancy and backups are manually performed, this setup has provided invaluable learning experiences. Within two months, I’ve gained a better understanding of my resource requirements than any capacity report could have provided. My platform, originally thought to be resource-heavy, has shown that it reaches only a peak of 4GB RAM usage. The extensive Kubernetes configuration I almost implemented would have been managing empty resources instead.
2. Hardcoded Constants
Instead of employing configuration files or environment variables, I rely on hardcoded constants such as:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While this may seem inefficient, it allows me to quickly locate any config value in my codebase with a simple search. Changes are tracked in git history and reviewed, albeit by myself. In just three months, I’ve altered these constants three times, resulting in a mere 15 minutes of redeployment compared to the 40 hours it would take to build a complex configuration management service.
