Embracing the 3-Month Rule: A Practical Approach to Building Unscalable Solutions

In the startup world, the mantra of “do things that don’t scale” is well known, thanks to thought leaders like Paul Graham. However, the challenge often lies in figuring out how to apply this approach, especially in the realm of software development. After spending eight months crafting my AI podcast platform, I’ve adopted a straightforward yet effective strategy: I give every quick fix or unscalable solution a span of three months to either prove its worth or be discarded.

The Realities of startup Development

As engineers, we often train ourselves to focus on scalable solutions from the outset. We revel in complex architectures—like microservices and distributed systems—that promise to support vast user bases. Yet, for those of us in the startup trenches, striving for scale too soon can become a costly form of procrastination. Instead of building for imagined problems encountered by hypothetical users, I believe in creating simple, direct solutions that ship quickly, allowing for real user feedback.

Key Infrastructure Insights

Here are some of my current unscalable hacks and the valuable lessons they’ve yielded:

1. Single VM Deployment

Currently, my entire stack—database, web server, background jobs, and caching—runs on one $40/month virtual machine. While this setup lacks redundancy and requires manual backups, it has provided invaluable insights. Within just two months, I learned my platform’s peak memory usage is a mere 4GB, which would have gone unnoticed had I invested in a more complicated architecture. The crashes I’ve experienced (twice thus far) taught me about real vulnerabilities, which were never what I originally expected.

2. Hardcoded Configurations

Instead of employing config files or environment variables, I make use of hardcoded constants throughout my code. Modifying any configuration requires a straightforward redeployment, but this simplicity offers a unique advantage. I can search my entire codebase to trace any configuration change at lightning speed, tracking every adjustment through Git history. In the past three months, I’ve only altered these constants three times, saving countless engineering hours by avoiding an extensive configuration service development process.

3. SQLite as a Database

I know it sounds unconventional, but my multi-user application uses SQLite. With a database size of just 47MB, it manages up to 50 concurrent users effortlessly. This scenario has revealed that my application’s usage pattern is dominated by reads rather than writes,