Embracing the 3-Month Rule: A Pragmatic Approach to Unscalable Solutions in Tech
In the tech industry, the notion of doing things that don’t scale is often championed, particularly by voices like Paul Graham. Yet, there seems to be a gap when it comes to actionable steps that can be taken in coding practices. After dedicating eight months to the development of my AI podcast platform, I’ve crafted a practical framework that revolves around a three-month experimentation cycle. Each “unscalable” solution gets just three months to demonstrate its worth; if it can’t prove itself, it’s time to move on.
As engineers, we’re conditioned to pursue scalable solutions from the outset. We often gravitate toward advanced architecture techniques such as microservices, distributed systems, and design patterns that are meant to support millions of users. However, this kind of thinking can lead to excessive caution in startup environments, where the focus should instead be on immediate user needs.
In many cases, laying down scalable code turns into costly procrastination, optimizing for users who don’t yet exist. My three-month rule encourages a more straightforward, albeit imperfect, coding approach that allows for rapid deployment and genuine feedback on what users truly require.
Current Unconventional Strategies: The Pragmatic Choices Behind Them
1. Single Virtual Machine for Everything
I’ve centralized my database, web server, and background jobs onto a single $40/month virtual machine (VM). While this setup lacks redundancy and relies on manual backups, the insight gained has been invaluable. Within merely two months, I’ve gauged my actual resource utilization better than any theoretical analysis could have provided. Knowing that my AI-focused platform rarely maxes out at 4GB RAM saved me from investing in an unnecessary Kubernetes setup. Each time the system fails, I gather real-time data that highlights genuine weak points—often not the ones I anticipated.
2. Hardcoded Constants Throughout Code
Instead of utilizing configuration files or environment variables, I have hardcoded certain parameters directly into my code, like pricing tiers and user limits. While this may sound unorthodox, it has hidden advantages: I can quickly search my entire codebase for any value, and every minor change is easily tracked through version history. Over three months, I’ve only adjusted these constants three times, allowing me to save substantial engineering hours.
3. SQLite Serving as Production Database
Yes, SQLite is my production database for a web application that supports multiple users. Its compact
