Embracing the 3-Month Rule: A Pragmatic Approach to Non-Scalable Solutions

In the tech startup landscape, it’s common to hear the advice from Paul Graham: “Do things that don’t scale.” However, the challenge lies in knowing how to effectively apply this wisdom to your coding practices.

After eight months of developing an AI podcast platform, I’ve established a personal framework: every non-scalable solution I implement is given a trial period of three months. At the end of this timeframe, I assess whether the approach has delivered tangible value and should be developed into a more robust solution, or if it should be discarded.

Rethinking Scalability

As engineers, we often prioritize creating scalable solutions from the outset—think design patterns, microservices, and sophisticated architectures intended for massive user bases. However, this mentality can lead to missed opportunities in a startup environment, where building for scale can be counterproductive. My three-month rule encourages me to prioritize simplicity and practicality in coding, allowing me to ship code quickly and learn directly from user interactions.

My Current Non-Scalable Infrastructure: Smart Choices

1. Unified Virtual Machine Setup

I’m currently running my entire infrastructure—database, web server, background jobs, and caching—on a single, cost-effective virtual machine for just $40 per month. While this setup lacks redundancy and relies on manual backups, it has provided invaluable insights into my actual resource requirements. In just two months, I learned that my AI-centric platform only requires 4GB of RAM at peak usage. The complex Kubernetes architecture I almost implemented would have gone to waste managing idle resources.

2. Directly Hardcoded Configurations

All my configurations, including pricing tiers and user limits, are hardcoded as constants throughout my codebase without using environment variables. Although this might seem inefficient, it allows me to swiftly track changes within my entire codebase. I’ve adjusted these values only three times over the past three months, saving significant development time compared to the hours it would take to set up a configuration service.

3. Production Use of SQLite

Yes, I’m utilizing SQLite for a multi-user application, maintaining a database size of merely 47MB. It easily accommodates around 50 concurrent users. This experience has revealed that my application leans heavily towards read operations (95%), making SQLite a fitting choice. Had I opted for Postgres from the start, I would have spent unnecessary time on connection pool optimizations for