Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Coding
In the world of startup development, the well-known mantra from Paul Graham—”Do things that don’t scale”—often meets some resistance. The challenge lies not just in adopting this philosophy, but in translating it into actionable practices within the realm of coding.
After eight months of developing my AI podcast platform, I’ve formulated a straightforward framework: each non-scalable solution I implement is given a lifespan of just three months. At the end of that period, I assess its value; it either warrants a refined version or is discarded.
Here’s a reality check: as engineers, we’re often conditioned to prioritize scalable architecture right from the outset—design patterns, microservices, distributed systems. While this intricate design is vital for established companies, at a startup, focusing on scalability too early may simply lead to delayed decisions and unnecessary complexity. Instead, my three-month guideline compels me to prioritize simplicity. I focus on writing code that is functional and delivers real insights about my users’ needs.
Current Infrastructure Strategies That Surprisingly Work:
1. All-in-One Server Approach
Everything from the database to the web server resides on a single $40/month virtual machine. This choice eliminates redundancy, and I handle backups manually.
Why is this a smart move? In the past two months, I’ve gained invaluable insight into my resource requirements that no theoretical planning document could have provided. My “AI-dependent” platform only peaks at 4GB of RAM, which suggests the extensive Kubernetes setup I had considered would have had empty containers to monitor. Whenever the system goes down—which has happened twice—I receive actual data on what fails; it’s rarely what I initially anticipated.
2. Hardcoded Values for Configuration
Rather than using config files or environment variables, I’ve opted for hardcoded constants throughout my codebase. Modifying any settings necessitates redeploying.
The unexpected advantage here is efficiency. I can rapidly search my codebase for any specific configuration variable. Each pricing adjustment is logged in git history, and every change undergoes a review process, albeit with just me evaluating my own pull requests. The time expenditure for such adjustments has amounted to only 15 minutes of deployment over three months, as opposed to investing an entire week on a configuration service.
3. SQLite as a Production Database
I’m utilizing SQLite for what is essentially a multi-user web application. My
