Embracing the 3-Month Rule: My Approach to Non-Scalable Coding
In the entrepreneurial tech landscape, one piece of advice resonates widely: “Do things that don’t scale.” However, the challenge lies in translating that wisdom into actionable coding strategies. After eight months of building my AI podcast platform, I’ve crafted a straightforward framework that operates on a three-month timeline—every unscalable hack I implement has just three months to prove its worth. At the end of that period, it either evolves into a robust solution or is discarded.
As engineers, we’re often conditioned to prioritize scalability from the outset, adhering to design patterns and creating complex infrastructures capable of managing thousands, if not millions, of users. However, this mindset can lead startups into a pit of expensive inefficiency, where we find ourselves optimizing for a future that may never arrive. By enforcing my three-month rule, I focus on creating straightforward, albeit imperfect, code that can be deployed promptly. This approach not only accelerates learning about user needs but also fosters genuine engagement with the project.
Current Infrastructure Hacks: Strategic Choices for Smart Learning
1. Consolidation on One Virtual Machine
I run my entire platform—including the database, web server, and background jobs—on a single $40/month virtual machine. While this setup lacks redundancy and relies on manual backups, the insights gained in just two months have been invaluable. By observing actual resource usage, I’ve learned that my AI-centric platform only peaks at 4GB of RAM, negating the need for a complex Kubernetes setup that would have ended up managing idle containers. Each occasional crash provides real data on failure points, shedding light on the unforeseen issues.
2. Hardcoded Configuration for Simplicity
My code features hardcoded constants like pricing tiers and user limits instead of complex configuration files or environment variables. While it may seem counterintuitive, this method simplifies tracking and quick refinements. Each value change is documented, and the time spent deploying changes amounts to mere minutes rather than the extensive hours that configuring a robust solution would have demanded.
3. Utilizing SQLite in Production
I’ve opted to run SQLite for my multi-user web application, which currently manages a database size of 47MB and accommodates up to 50 users seamlessly. Analyzing my access patterns revealed an imbalance of 95% reads to 5% writes, making SQLite the perfect fit. Starting with a heavier solution like Postgres would have led to
