The 3-Month Rule: A Technical Framework for Embracing Unscalable Solutions
When it comes to building products, many of us are familiar with the wisdom of Paul Graham: “Do things that don’t scale.” However, the application of this principle in software development often goes unexplored.
As I have spent the past eight months developing my AI podcast platform, I’ve established a straightforward framework: allow each unscalable approach or hack to exist for a limited time of three months. After this period, it either proves its worth and evolves into a robust solution, or it is phased out.
It’s essential to recognize that as engineers, we are often conditioned to prioritize scalable designs from the outset—thinking in terms of elegant architectures, microservices, and systems capable of accommodating millions of users. While this approach is valuable for large enterprises, in the startup ecosystem, it can lead to excessive investment in solutions for problems that may never arise. My three-month rule encourages me to create straightforward, even “poorly-designed” code that enables rapid deployment and insightful learning about real user needs.
Infrastructure Choices: Why My Current Hacks Work
1. Unified VM for Everything
I’ve opted to run my entire infrastructure—database, web server, background processes, and caching—on a single virtual machine costing just $40 a month, with zero redundancy and manual local backups.
This decision has proven to be strategic rather than foolish. Within a span of two months, I’ve gained invaluable insights into my actual resource requirements. For instance, I’ve discovered that my platform peaks at 4GB of RAM, underscoring how unnecessary a complex Kubernetes setup would have been. When crashes have occurred (and they have twice), I’ve identified the real causes—not always what I anticipated.
2. Hardcoded Configuration
My configuration is essentially hardcoded: constants like PRICING and MAX_USERS are embedded directly in the codebase.
Though this might seem counterintuitive, it simplifies tracking and modifying configurations. Every change is documented in version control, and I can quickly search the codebase for any value. Building a configuration service would require significant development time, but since I’ve only changed settings three times in three months, this straightforward method has saved me countless engineering hours.
3. Utilizing SQLite in Production
Yes, SQLite is powering my multi-user web application, and it’s performing admirably with a total database size of 47MB, effortlessly managing 50 simultaneous users.
This choice has illuminated key access
