The 3-Month Doctrine: A Pragmatic Approach to Non-Scalable Coding
In the startup world, the idea of “doing things that don’t scale” is often echoed, particularly by industry thought leaders like Paul Graham. However, there’s a notable gap when it comes to translating this advice into practical coding strategies. After dedicating eight months to developing my AI podcast platform, I’ve devised a straightforward methodology: every unscalable solution receives a trial period of three months. Post-trial, it either proves its value and evolves into a robust implementation or is retired.
As engineers, our instinct is to create scalable systems from the outset, embracing complex design patterns, microservices, and distributed architectures. This approach suits larger enterprises, but in a startup setting, such scalability can turn into costly procrastination. We’re frequently busy tweaking systems for hypothetical users rather than addressing the real needs of our current audience. My three-month rule compels me to deploy simpler, more direct code that facilitates quick iterations and uncovers genuine user requirements.
My Current Infrastructure Hacks and Their Benefits
1. Single VM Operation
Currently, all my components—database, web server, background jobs, and caching—run on a single, budget-friendly $40/month virtual machine. While this setup lacks redundancy and involves manual backups, it has taught me a great deal about my actual resource demands in just two months. Instead of wasting time on elaborate capacity planning, I learned that my “AI-heavy” platform typically requires only 4GB of RAM. The sophisticated Kubernetes configuration I almost implemented would likely have resulted in unused containers.
When the system experiences outages (which has happened twice), I get invaluable insights into what malfunctions. Interestingly, it’s seldom what I anticipated.
2. Hardcoded Configuration
In my current setup, configuration values are hardcoded directly into the code, for example:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no separate configuration files or environment variables; any modifications necessitate a redeployment. This seemingly rudimentary approach has a hidden advantage: I can search my entire codebase for any configuration value in seconds. Each price adjustment is traceable in version history, ensuring that every update is part of a deliberate review process—albeit self-driven.
Creating a separate configuration service could take as much as a
