Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Development
In the world of startups, particularly in tech development, we often hear the adage, “Do things that don’t scale,” famously advocated by Paul Graham. While this advice is well-known, the challenge lies in implementing it effectively, especially in coding practices.
After eight months of building my AI podcast platform, I’ve established a straightforward principle: any unscalable solution has a life expectancy of three months. At the end of this period, it must either demonstrate its value and evolve into a robust solution or be discarded.
The Dilemma of Scalability in startup Development
As engineers, we are conditioned to prioritize scalable solutions right from the outset. We delve into intricate design patterns, microservices, and architectures capable of accommodating substantial user volumes—this is the mindset of larger corporations. However, in a startup environment, the pursuit of scalable solutions can often lead to costly uncertainties, focusing on potential users who may never engage with our platform.
My 3-month rule encourages me to adopt a more pragmatic approach by allowing me to write straightforward, albeit imperfect, code that can be launched and tested in the real world. This method ultimately reveals genuine user needs and behaviors, steering the next steps of development.
Current Infrastructure Strategies: Simple Yet Effective
Here are some of my current practices that may seem rudimentary but have proven to be quite insightful:
1. Consolidated Infrastructure on a Single VM
I operate my web server, database, background jobs, and caching—all on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups to my local system, it has provided invaluable insights into my resource needs. Unexpectedly, my AI platform has only peaked at 4GB of RAM usage, rendering the complex Kubernetes framework I was considering unnecessary. Each crash has given me pertinent data about failure points, which often differ from my expectations.
2. Hardcoded Configurations Across the Codebase
Instead of abstract configuration files or environment variables, I utilize hardcoded constants throughout my code. For example:
python
PRICE_TIER_1 = 9.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This approach allows me to quickly search for configuration values using grep. With only three changes in three months, the simpler method saves me countless hours that would have been spent on developing a dedicated configuration
