The 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions in Development
In the world of startups and innovation, Paul Graham’s well-known mantra, “Do things that don’t scale,” resonates deeply. However, as developers, we often grapple with the challenge of how to translate this philosophy into our coding practices. After spending eight months crafting my AI podcast platform, I’ve established a guiding principle: each non-scalable workaround is granted a three-month trial period. After this timeframe, the hack either proves its worth and is refined into a sustainable solution or it is discarded.
Rethinking Scalability
As engineers, we’re conditioned to pursue scalable solutions from the outset. We study design patterns, microservices, and distributed systems—architectures that can accommodate millions of users. However, this mindset can be counterproductive in a startup environment. Early on, focusing on scalability might lead to unnecessary complexity and cost. My three-month approach compels me to embrace straightforward, albeit imperfect, code that can be deployed quickly to reveal genuine user needs.
Current Infrastructure Strategies: Practical and Insightful
1. Consolidated Operations on a Single VM
Currently, my database, web server, background tasks, and Redis all operate on a single $40-per-month virtual machine. Yes, I lack redundancy and perform manual backups—but this structure has provided unexpected insights. Within just two months, I’ve gained a clearer understanding of my resource demands than any extensive capacity planning could provide. It turns out that my platform, laden with AI processes, only peaks at 4GB of RAM. The intricate Kubernetes environment I contemplated would have only resulted in wasted resources managing idle containers. Additionally, when my system crashes (which has happened a couple of times), I gather real data on failures—often not what I had anticipated.
2. Simplified hardcoded Configurations
Instead of utilizing configuration files or environment variables, I’ve opted for hardcoded constants throughout my codebase. Modifications require redeployment, but the benefits are notable. It allows me to search for any configuration value quickly, and every price adjustment is documented within my Git history. This simplicity dramatically reduces engineering hours; I’ve adjusted these constants only three times in the past three months—far less time than setting up a configuration service would have taken.
3. Utilizing SQLite in Production
In what might raise eyebrows, I am currently running SQLite in a web app designed for multiple users. My entire database weighs in
