Embracing the 3-Month Rule: A Framework for Learning Through Code
In the startup world, few pieces of advice resonate as strongly as Paul Graham’s mantra: “Do things that don’t scale.” While many of us are familiar with this philosophy, it can be challenging to translate it into concrete actions, especially when it comes to coding practices. Over the past eight months as I’ve been developing my AI podcast platform, I’ve devised a straightforward yet effective framework: each unscalable approach gets a trial period of three months. If it proves its worth, it gets refined. If not, it’s time to let it go.
As software engineers, we are often trained to focus on scalable solutions right from the start—think of all the design patterns, microservices architectures, and distributed systems concentrating on high user volumes. But for startups, chasing scalability too early can lead to wasted resources and missed insights. My three-month rule encourages writing straightforward, sometimes “bad” code that gets deployed rapidly, allowing me to uncover the real needs of my users without the analysis paralysis that can accompany grand architectures.
Current Infrastructure Hacks: Smart Choices for Quick Learning
1. Consolidated Operations on a Single VM
Instead of distributing functions across multiple servers, I’ve opted to run my database, web server, background jobs, and other components on a single $40/month virtual machine (VM). While this completely pooled setup lacks redundancy and relies on manual backups, it’s been invaluable for understanding my actual resource requirements. Within two months, I learned my platform peaks at a mere 4GB RAM. My idea of a sophisticated Kubernetes setup would have meant managing empty containers. Each crash (and I’ve had two) has shed light on the precise issues at hand—often surprising ones.
2. Hardcoded Configurations
Instead of utilizing external configuration files, I have constants embedded throughout my code:
python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"
Every change requires a redeployment, which may appear cumbersome. However, this simplicity permits rapid searches across my entire codebase, allowing for instant visibility into the history of every configuration. Building a dedicated configuration service would take significant time, yet I’ve only modified these values three times in three months—a 15-minute redeployment versus an allocation of forty hours for engineering.
**3.
One Comment
This post offers a compelling perspective on embracing unfashionable yet effective development practices in the early stages of a startup. I particularly appreciate the emphasis on rapid iteration over premature optimization—it’s a great reminder that understanding user needs often requires hands-on experimentation rather than theoretical perfection.
The three-month trial period is a practical way to balance action and reflection, ensuring that unscalable solutions are given a fair shot before evolving. Your example of consolidating operations on a single VM resonates with the Lean Startup ethos: reducing complexity to gain clarity. Many developers hesitate to deploy “bad” code because of vanity or fear, but as you highlight, these rough approaches facilitate learning and quick pivots.
Also, your use of hardcoded configurations demonstrates a pragmatic approach—favoring speed and visibility over the initial robustness often associated with best practices. While not suitable for production at scale, such hacks are invaluable for rapid validation.
I’d love to hear how you plan to transition from these unscalable practices once you’ve validated your assumptions. Do you have a roadmap for iteratively scaling up, or do you see certain strategies as ongoing trade-offs? Overall, your framework is a refreshing reminder that sometimes, doing things that don’t scale is precisely what leads to meaningful, user-driven growth.