The Three-Month Experiment: A Practical Approach to Building Solutions That Don’t Scale
In the world of startups, the mantra “Do things that don’t scale,” popularized by entrepreneur Paul Graham, is often tossed around. However, it’s surprising how little guidance there is on actively applying this concept within the realm of software development. Over the past eight months, while working on my AI podcast platform, I’ve adopted a framework that has drastically shifted my approach to coding.
My Three-Month Rule
My strategy is straightforward: every hack or workaround that is inherently unscalable is given a lifespan of three months. After this period, each hack must either demonstrate its usefulness and be developed into a scalable solution or be discarded entirely.
As engineers, we have been conditioned to think about scalability from the outset. We often envision complex architectures—microservices, distributed systems, and intricate design patterns—suitable for handling millions of users. But in a startup environment, focusing on scalability too soon can lead to unnecessary complications and wasted resources, as we may end up optimizing for hypotheticals rather than real user data.
Learning Through Simplicity: My Current Infrastructure Hacks
1. Consolidating on One Virtual Machine
All components of my application—database, web server, background processing, and caching—run on a single $40/month virtual machine (VM) with no redundancy and manual backups to my local machine.
Why is this a smart move? In just two months, I’ve gained invaluable insights into my resource needs that any capacity planning document could not provide. As it turns out, my application doesn’t require the elaborate infrastructure I initially envisioned; it peaks at a mere 4GB of RAM. Instead of managing empty containers, I’m getting real-time data about what causes crashes, which—surprisingly—has never been what I anticipated.
2. Hardcoding Configuration Values
Throughout my code, you’ll find constants such as:
plaintext
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
There are no config files or environment variables involved—just constants across various files. This choice does come with trade-offs, but the benefit is significant. I can efficiently search my entire codebase for any configuration value within seconds, and any changes are tracked in git history. My workflow has been streamlined; modifications have occurred only three
One Comment
This post offers a compelling perspective on balancing rapid experimentation with thoughtful scaling. I appreciate how the Three-Month Rule encourages developers to prioritize immediate learning and validation over premature optimization. The example of consolidating resources onto a single VM resonates with the practical attitude needed in early-stage startups—often, complexity is the enemy of agility.
Hardcoding configuration values might seem counterintuitive from a best practices standpoint, but in the context of rapid iteration, it makes sense. It allows for quick changes and reduces friction during the development phase. Of course, as the project matures, transitioning to more flexible configurations will be essential, but your framework wisely emphasizes the importance of context-driven decisions.
Overall, this approach reminds me that engineering solutions should serve the current needs first and foremost, with scalability being a secondary concern until justified. It’s a pragmatic reminder that sometimes, doing “unscalable” things is the most effective way to learn, adapt, and grow.