Title: Embracing Unsustainable Coding: The 3-Month Experimentation Framework
In the startup landscape, there’s a well-known adage that emphasizes the importance of “doing things that don’t scale,” as famously articulated by tech luminary Paul Graham. While the advice is widely recognized, the challenge often lies in its practical application within software development. After eight months of developing my AI podcast platform, I’ve adopted a straightforward approach—known as the 3-Month Rule—for integrating unscalable solutions into my coding practice. This rule dictates that each hack is granted a temporary lifespan of three months, during which it must demonstrate its value or be discarded.
As software engineers, our training often leans towards creating scalable systems from the outset. We delve into design patterns, microservices, and lift-and-shift frameworks that promise to support vast user bases as we visualize our solutions’ expansive futures. However, in the vibrant chaos of a startup, pursuing scalability can transform into an expensive form of delay, as we tend to optimize for hypothetical users and challenges that may never arise. My approach compels me to prioritize workable, albeit imperfect, code that provides real insights into user needs—often revealing trends that are not aligned with our initial assumptions.
Current Infrastructure Hacks: Why They Work for Me
1. All-In-One VM
I operate with a single virtual machine (VM) that hosts my database, web server, background processes, and Redis on a cost-effective $40/month plan. While this setup lacks redundancy and requires manual backups, it has significantly improved my understanding of actual resource demands. Within just two months, I discovered my “AI-heavy” platform demands only 4GB of RAM, steering clear of the time-consuming Kubernetes setup I almost implemented. This crash course in hands-on troubleshooting has provided invaluable insights into unforeseen bottlenecks.
2. Unconventional Hardcoded Configurations
Instead of relying on configuration files or environment variables, I’ve opted for hardcoded constants scattered throughout my codebase, such as:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
While some might deem this approach inefficient, it allows me to swiftly search through my code to locate configuration values, with every change documented in Git history. The time saved in avoiding an extensive configuration service has far outweighed the brief redeployment times
