Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions
In the world of startups and tech innovation, Paul Graham’s famous mantra, “Do things that don’t scale,” resonates deeply. However, many developers struggle with how to effectively incorporate this wisdom into their coding practices. After eight months of developing my AI podcast platform, I stumbled upon a practical framework: if a non-scalable hack isn’t proven useful within three months, it either gets developed into a robust solution or is discarded.
The Challenge of Scaling from the Outset
As software engineers, we often find ourselves conditioned to prioritize scalable solutions right from the start. We immerse ourselves in sophisticated architecture, employing design patterns, microservices, and distributed systems with the goal of accommodating millions of users. However, this mindset can hinder startups, as focusing on scalability can mean lingering on optimizations for potential users that don’t even exist yet. My 3-month rule challenges me to create straightforward, sometimes “imperfect” code that can be deployed quickly, facilitating learning about user needs in a practical context.
Current Hacks in My Infrastructure: Smart Choices for Learning
1. Consolidated Operations on a Single Virtual Machine
Everything runs from one affordable $40/month VM that hosts the database, web server, background jobs, and even Redis. Yes, there’s no redundancy and backups are done manually to my local machine, but this approach has been enlightening. Within just two months, I’ve gained insights into my actual resource consumption—my platform’s peak usage is a mere 4GB of RAM. The complex Kubernetes architecture I nearly implemented would have only managed dormant containers.
When the system crashes (which it has, twice so far), I glean valuable insights into what fails, and it’s rarely what I anticipate.
2. Hardcoded Configurations for Simplicity
Constants like:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
are directly embedded in the code. There are no configuration files or environment variables, which means that any change entails redeployment. The advantage of this method? Rapid searches across the codebase for any configuration value. Each price alteration is meticulously tracked through git, and every configuration update, albeit by me, undergoes review.
Spending a week to construct a configuration service simply doesn’t compare to the couple
