Embracing the 3-Month Experiment: A Technical Approach to Non-Scalable Solutions
In the tech start-up world, the iconic advice from Paul Graham resonates deeply: “Do things that don’t scale.” Yet, few discuss how to translate this principle into practical application, especially for coding. After spending eight months developing my AI podcast platform, I’ve established a personal framework that I refer to as the “3-Month Rule.” Simply put, any non-scalable solution I implement is given a three-month trial period. If it proves its worth in that timeframe, I’ll invest in a proper build-out; if not, it’s time to move on.
Many engineers, myself included, are often schooled on crafting scalable solutions from the onset. We dive into sophisticated architectures with the intent to cater to millions—think design patterns, microservices, and distributed systems. However, this may not be the most productive mindset for a start-up. In reality, focusing on scalability too early can lead to costly delays, as we find ourselves optimizing for hypothetical users while neglecting immediate needs. My 3-Month Rule empowers me to focus on straightforward, albeit imperfect, code that gets deployed quickly, allowing me to gather real feedback on what users truly require.
Current Low-Tech Hacks That Are Working Well
1. Simplistic Infrastructure on a Single VM
Currently, I host my database, web server, background jobs, and Redis all on a single $40/month virtual machine. There’s no redundancy, and backups are done manually to my local machine.
This approach has its merits: in just two months, I’ve gained more insight into my actual resource usage than any detailed planning document could provide. For instance, my platform’s peak usage only reaches 4GB RAM. The intricate Kubernetes setup I almost pursued would have resulted in managing idle containers instead. When issues arise (and they have), I receive valuable, real-time feedback about what’s failing—often surprising me with the source of the issue.
2. Directly Hardcoded Configurations
Variables like PRICE_TIER_1 = 9.99 and MAX_USERS = 100 are hardcoded throughout my files. This may seem inefficient, but it allows for rapid changes and quick deployment—tweaking values takes a mere 15 minutes instead of the extensive time it would take to develop a configuration management system that I would use sparingly.
Every price adjustment is logged in Git
