Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions
In the world of startups, the advice from tech luminary Paul Graham to “do things that don’t scale” has become a mantra. However, as engineers, the transition from theory to practice is often overlooked, especially in the realm of coding. After dedicating eight months to developing my AI podcast platform, I’ve discovered an effective framework: every non-scalable solution will have a lifespan of just three months. If it proves its worth, I’ll refine it into a scalable solution; if not, it will be phased out.
The Startup Mindset: Rethinking Scalability
As developers, we’re often conditioned to aim for scalability right from the outset. We think in terms of design patterns, microservices, and elaborate architectures intended to support millions of users. While this approach is sound for large companies, at a startup level, it can often lead to unnecessary complications and wasted resources. My three-month rule compels me to write straightforward, albeit imperfect, code. The goal is to deploy swiftly and understand my users’ needs genuinely.
My Current Strategies: Pragmatic Infrastructure Hacks
1. Consolidated Operations on a Single VM
I’m running my database, web server, background jobs, and caching system all on a single $40/month virtual machine. This setup sacrifices redundancy and relies on manual local backups, but it’s been illuminating.
In two months, I’ve gained insight into my actual resource usage that far exceeds what any capacity planning document could provide. My platform typically peaks at just 4GB of RAM. The extravagant Kubernetes system I contemplated would have resulted in managing idle containers. Every time the system crashes—which has occurred twice—I receive concrete feedback on what truly needs addressing.
2. Hardcoded Options for Simplified Configuration
Instead of the usual approach of creating configuration files or using environment variables, I utilize hardcoded constants throughout the codebase. This means any updates require redeployment, which initially seems inconvenient.
The benefit of this method is profound: I can quickly search for configuration values across my entire codebase. Each pricing change and configuration update is meticulously recorded in version history. In the past three months, I’ve changed those values just three times, saving significant time compared to the potential hours spent on developing a configuration service.
3. SQLite for a Multi-User Application
Surprisingly, my dynamic web application relies on SQLite
One Comment
This post beautifully illustrates the power of a pragmatic, experimental approach to startup engineering—especially the value of quick iterations and real-world feedback within a constrained timeframe. The “3-month rule” not only helps validate ideas rapidly but also prevents over-engineering early on, which is a common pitfall.
I particularly appreciate the emphasis on simplified infrastructure strategies, such as consolidating operations on a single VM and using hardcoded configurations. These methods favor agility and reduce complexity, enabling faster learning cycles. The use of SQLite for a multi-user app is also a compelling reminder that choosing the right tool for the scale and scope of a project can significantly streamline development.
As someone who’s navigated the balance between “doing things that don’t scale” and planning for growth, I would add that this approach encourages a mindset of continuous validation. After the initial three months, carefully measuring the outcomes and user feedback will guide whether to double down or pivot—ultimately leading to more sustainable and user-focused solutions. Thanks for sharing this insightful framework!