Embracing the 3-Month Experimentation Framework: A Practical Approach to Unscalable Solutions
In the world of startups and innovative projects, the mantra “Do things that don’t scale,” popularized by Paul Graham, often echoes in our ears. However, the challenge lies not just in acknowledging this principle but in effectively putting it into practice—especially within the realm of coding. Having worked on my AI podcast platform for the past eight months, I’ve developed a unique framework that encourages experimentation: any unscalable solution receives a trial period of three months. After this window, it must either demonstrate its value and be transformed into a reliable solution, or it gets discarded.
As engineers, we tend to focus on scalability from the outset, employing design patterns, microservices, and distributed systems—all aimed at preparing for a future that may not even materialize. Yet, in the startup world, such approaches can become costly detours, often preemptively optimizing for non-existent users and addressing problems that might never come our way. My 3-month rule compels me to utilize straightforward, albeit imperfect, code that leads to live deployments and valuable insights into user needs.
Current Hacks and Their Unexpected Wisdom
- Unified Virtual Machine (VM) Approach
I run everything—from the database to background jobs—on a single, budget-friendly $40/month VM. There’s no redundancy and manual backups to my local system. This configuration has provided invaluable insights that no elaborate planning document could offer. For instance, I discovered that my platform, which I initially anticipated would require extensive resources, actually peaks at just 4GB of RAM. My near-attempt to set up Kubernetes would have resulted in managing an inefficient system filled with idle containers.
- Hardcoded Variables Across the Board
Rather than implementing complex configuration files or using environment variables, I utilize hardcoded constants throughout my code. Making changes requires a simple redeployment, allowing me to track all modifications through Git history easily. This approach saves me significant engineering time—changing pricing tier values takes only 15 minutes of redeployment compared to a potential 40-hour development project to establish a configuration service.
- SQLite for Production Use
Running a multi-user web app with SQLite might seem unconventional, but with a compact 47MB database, it efficiently handles 50 simultaneous users. This has revealed that my access patterns heavily favor read operations over writes—95% to 5%, respectively. If I had opted for
