Embracing the 3-Month Rule: A Practical Approach for Startups
When it comes to startup culture, few phrases resonate as much as Paul Graham’s advice to “do things that don’t scale.” However, translating this philosophy into actionable coding practices often goes unaddressed. After spending eight months developing my AI podcast platform, I’ve crafted a straightforward framework: every unscalable hack is given a lifespan of just three months. At the end of this period, we reassess: if it has delivered tangible value, we build it out properly; if not, it gets the axe.
As engineers, we tend to lean heavily on the creation of scalable solutions right from the start. Whether it’s intricate architecture for handling millions of users or advanced techniques like microservices, we often find ourselves trapped in the mindset of big organizations. But in the world of startups, implementing scalable code can become a costly diversion. We’re frequently optimizing for future users who aren’t even in the pipeline yet or tackling problems that might never arise. My three-month guideline encourages me to focus on direct, no-frills code that actually gets deployed while allowing us to discover what users truly require.
Current Infrastructure Hacks and Their Surprising Benefits
1. Consolidation on a Single Server
Everything runs from one virtual machine (VM)—the database, the web server, the background jobs, and even Redis—all for just $40 a month. There’s no redundancy, and backups are done manually.
This approach provides valuable insights about our resource usage. In less than two months, I’ve learned that my “AI-heavy” platform typically requires just 4GB of RAM. A complex Kubernetes setup would have been a waste of time managing empty containers. And when the server crashes (which has happened a couple of times), I get genuine feedback on system vulnerabilities—often in ways I didn’t anticipate.
2. Hardcoded Values for Configuration
With constants like:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
There are no external config files or environment variables—just hardcoded values throughout my codebase. Modifying any parameter necessitates a redeployment.
This strategy allows for rapid searches across my codebase for specific configurations. Price changes are easily tracked through Git history and reviewed in a straightforward way. Devoting a week to build a configuration service seems pointless when I’ve only made three changes in three
One Comment
Great insights! I appreciate how you’ve operationalized the “do things that don’t scale” philosophy with your 3-month rule. It’s a practical approach that balances experimentation with disciplined reassessment. Your example of consolidating everything onto a single VM is an excellent demonstration of how focusing on simplicity and rapid learning can reveal real user needs and system vulnerabilities early on.
Additionally, your use of hardcoded values for configuration highlights a valuable point: sometimes, maximizing agility and speed in the early stages outweighs the benefits of premature abstraction. As you’ve shown, these hacks provide immediate feedback and foster quick iteration, which are crucial in a startup environment.
One suggestion for future iterations might be to formalize a knowledge-sharing process around these hacks, so if certain patterns or solutions prove valuable, they can be documented and gradually refactored into more scalable components as your platform matures. This way, the “hack” becomes a stepping stone toward more robust solutions rather than a long-term crutch. Overall, your disciplined approach to balancing “doing what doesn’t scale” with strategic reassessment is a strong model for startup engineering.