Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions
In the tech startup world, one piece of advice that often resonates is Paul Graham’s principle: “Do things that don’t scale.” However, the challenge lies in effectively applying this philosophy, especially when it comes to coding practices that aim to propel your project forward without the initial burden of scalability.
After dedicating eight months to building my AI podcast platform, I’ve found a straightforward yet effective strategy to navigate this. I call it the “3-Month Rule.” Each non-scalable solution I implement is given a window of three months to demonstrate its worth. If it proves beneficial, it will be refined. If not, it gets shelved.
As engineers, we often gravitate towards scalable solutions right from the beginning, favoring sophisticated designs, microservices, and distributed systems that promise to support millions of users. Yet, such approaches can hinder startups, as they often lead to unnecessary complexity. My experience with this framework has shown that prioritizing immediate, simple solutions can yield far more insights about user needs.
Current Infrastructure Strategies: My Unconventional Choices
1. Unified Hosting on a Single VM
I’m currently running my entire system—including the database and web server—on a single $40/month virtual machine (VM). This setup features no redundancy and relies on manual backups.
Why is this a smart move? It has allowed me to quickly grasp my resource needs in just two months, revealing that my “AI-heavy” application peaks at 4GB of RAM. Instead of diving headfirst into a complex Kubernetes architecture, I’ve spent less time managing non-essential infrastructure and more time understanding real user interactions.
2. Hardcoded Constants Across the Board
Instead of employing configuration files or environment variables, I’m utilizing hardcoded constants. This means changes necessitate a redeploy each time.
This method has its advantages: with a simple grep, I can locate any configuration value within seconds. Each adjustment I’ve made over the past three months has been meticulously logged in git history and gone through my own code review. Rather than dedicating weeks to construct a configuration service, I’ve opted for a solution that has required only 15 minutes of redeployment time throughout that period.
3. Using SQLite in a Multi-User Context
Yes, I’m leveraging SQLite for my multi-user application. My entire database size is a mere 47MB, and it comfortably supports up to
