The 3-Month Framework: A Pragmatic Approach to Imperfect Solutions
In the realm of entrepreneurship, Paul Graham’s adage—“Do things that don’t scale”—is often cited, yet seldom explored in practical terms, especially in the context of software development. After eight months of developing my AI podcast platform, I’ve established a straightforward framework that embraces this philosophy: every hack that lacks scalability is granted a lifespan of three months. At the end of this period, it’s either validated and upgraded, or it is discarded.
As developers, we are conditioned to prioritize scalable solutions from the outset—think complex architectures, microservices, and distributed systems—all engineered to accommodate millions of users. However, this big-company mindset can hinder startups where optimizing for users that don’t yet exist often leads to costly delays. My three-month rule encourages me to create simplified, less elegant code that gets deployed, providing invaluable insight into what users truly need.
Smart Hacks in My Current Infrastructure
Here are some of the strategic decisions I’ve made, alongside the rationale that underpins their effectiveness:
1. Consolidation on a Single Virtual Machine
All necessary services—from the database to the web server—are running on a single $40/month virtual machine. Yes, there’s no redundancy, and manual backups are performed to my local machine.
This approach has proven remarkably insightful; in just two months, I have gained more clarity on my resource requirements than any theoretical planning document could offer. Surprisingly, my “AI-heavy” platform only uses 4GB of RAM at peak times. Had I jumped into setting up Kubernetes, I would have been managing empty containers, rather than addressing meaningful challenges.
When the VM goes down (which has happened twice), I receive concrete data on failures—often not what I anticipated.
2. Hardcoded Configuration
Consider this structure:
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Rather than utilizing config files or environment variables, I’ve employed hardcoded constants throughout my codebase. This means any change necessitates a redeploy.
The upside? I can swiftly search my entire code for any configuration value. Each price alteration is documented in the Git history, and I maintain control over updates—even if I’m the only reviewer. Building a dedicated configuration service would consume a week; instead, I’ve made three changes in three months
One Comment
This is a fantastic illustration of how embracing the “do things that don’t scale” philosophy can lead to rapid learning and smarter iteration. Your 3-month rule provides a clear, disciplined approach to balancing experimentation with pragmatism—allowing you to prioritize validated insights over perfection from the start.
I especially like the emphasis on simplicity, such as consolidating on a single VM and using hardcoded configs during initial phases. These choices minimize overhead and allow for quick adjustments, which is crucial in early-stage product development. As you point out, this approach fosters a more tangible understanding of real-world resource demands and user needs.
One potential area to consider as you evolve is gradually introducing more scalable practices—such as external configs or automated backups—as your platform grows and becomes more stable. But the key takeaway is maintaining the flexibility to experiment and iterate fast, leveraging time-bound hacks as a means to uncover what truly works. Thanks for sharing this insightful framework!