Embracing the 3-Month Rule: A Practical Approach to Non-Scalable Solutions in Tech
In the tech world, much is said about the principle of “doing things that don’t scale,” a notion popularized by Paul Graham. However, the real challenge lies in effectively applying this philosophy within the confines of software development. As a founder of an AI podcast platform, I’ve spent the last eight months crafting a straightforward yet effective framework: each non-scalable solution is given a three-month trial period. After this duration, I assess whether the solution proves its worth and warrants proper implementation, or whether it should be phased out.
In the startup landscape, the tendency is to begin with an eye on scalability. With a focus on sophisticated architectures like microservices and distributed systems, many engineers lose sight of the actual needs of their current user base. This mindset often leads to creating overly complex systems that address theoretical scenarios rather than real-world demands. My three-month rule prompts me to develop simple and functional code that enables fast learning about user requirements.
Current Infrastructure Hacks: Smart Choices That Yield Insights
1. Consolidating Resources on a Single VM
I currently run everything—from the database to the web server—on a single, cost-effective VM. While this approach may seem reckless at first glance, it has provided invaluable insights regarding resource allocation. These two months on this setup revealed that my AI-centric platform peaks at just 4GB of RAM. The complex Kubernetes architecture I was considering would have been managing resources unnecessarily. Each crash yields real-time data, illuminating actual failure points—often not what I initially expected.
2. Simplified Configuration Management
Instead of relying on extensive config files or environment variables, I use hardcoded constants for settings such as price tiers and user limits. Although deploying changes means a simple redeployment, having these values in the codebase enables rapid searching and tracking. Over three months, I’ve only needed to modify them a few times, resulting in significant time savings compared to developing a dedicated configuration service.
3. Leveraging SQLite for Efficiency
Running SQLite for a multi-user web application might raise eyebrows, yet it has proven adequate for my entire database needs—currently a mere 47MB. This choice has revealed a significant insight: my usage pattern consists of 95% reads and only 5% writes—perfectly suited for SQLite. If I had chosen a solution like Postgres from the outset, I would have needed to navigate unnecessary complexities like connection
