Embracing the Three-Month Rule: A Tactical Approach to Non-Scalable Solutions
In the tech world, the phrase “Do things that don’t scale” is often attributed to Paul Graham, yet there’s insufficient guidance on how to actualize this idea in a coding environment. After dedicating eight months to developing my AI podcast platform, I’ve created a straightforward framework: any hack that lacks scalability receives a three-month trial period. If it proves its worth within that timeframe, it gets more comprehensive development; if not, it gets phased out.
As engineers, we’re conditioned to focus on scalability from the outset. We admire intricate architectures involving microservices and distributed systems designed to accommodate millions of users, reflective of the mindset prevalent in larger corporations. However, in a startup environment, attempting to build scalable solutions too soon often amounts to excessive procrastination—spending time optimizing for hypothetical users instead of addressing current demands.
My three-month rule compels me to write straightforward, albeit imperfect, code that is deployable, allowing me to grasp user needs more effectively.
Current Infrastructure Hacks: Smart Choices Over Complex Solutions
1. Unified Virtual Machine Environment
Currently, my entire infrastructure—database, web server, background jobs, and caching—is operating on a single $40/month virtual machine without any redundancy. Backup is manually executed on my local machine for added control.
Why this approach works: Within two months, I have gained a better understanding of my resource requirements than any elaborate capacity planning document could provide. My AI-driven platform operates efficiently with just 4GB RAM, proving that the complex Kubernetes architecture I nearly implemented would have been managing largely unused resources. Each crash (which has happened twice) provides valuable insights into what truly fails, consistently revealing unexpected weaknesses.
2. Static Configuration Settings
I avoid using configuration files or environment variables, opting instead for hardcoded constants. For instance:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
This approach might seem primitive, but it offers a unique advantage: I can search through my codebase and pinpoint configuration values with ease. Changes prompt immediate redeployment, and I’ve discovered that I’ve only adjusted these values thrice over three months, saving an immense amount of engineering time.
3. Deploying SQLite in Production
Yes, SQLite powers my multi-user
