The Three-Month Experiment: A Pragmatic Approach to Unscalable Solutions

In the startup world, the advice from technologist Paul Graham to “do things that don’t scale” is widely acknowledged. Yet, few discuss the practical application of this principle, particularly in coding.

After eight months of developing my AI podcast platform, I’ve crafted a straightforward approach: every unscalable solution is given a lifespan of three months. Post this period, it either demonstrates its effectiveness and is re-engineered for permanence, or it’s discarded.

As engineers, we frequently fall into the trap of designing for scalability right from the outset. We dream in terms of microservices, distributed systems, and sophisticated architectures meant to cater to millions of users. This is an approach more suited to established companies than to startups. In early-stage ventures, focusing solely on scalable solutions can lead to costly delays. My three-month framework compels me to produce straightforward, albeit “imperfect,” code that leads to real deployments and critical insights into user needs.

Current Infrastructure Hacks: Why They Work

1. Single VM for Everything

My entire application—database, web server, background jobs, and cache—operates on a single $40/month virtual machine. There’s no redundancy in sight, and I manually execute backups.

This approach has proven beneficial rather than detrimental. Within two months, I’ve gained insights into my resource demands that no capacity planning document could provide. It turns out, despite branding my platform as “AI-heavy,” it typically operates at just 4GB of RAM. The complex Kubernetes setup I had contemplated would have been managing idle containers.

Each time the system crashes (which has happened a couple of times), I gather invaluable data about the failures—often revealing surprises about what actually goes wrong.

2. Hardcoded Configuration Values

Instead of utilizing configuration files or environment variables, I’m relying on constants scattered throughout my codebase. Adjusting any parameter involves a full redeployment, but this setup allows me to swiftly search my entire code for any configuration value. Each change is preserved in Git history, and I conduct personal code reviews.

The time-saving aspect is clear: creating a configuration service would cost a week of work. In the last three months, I’ve altered these constants just three times—resulting in 15 minutes of redeployment versus 40 hours of development.

3. SQLite for a Multi-User Platform

Yes, I’m using SQLite for my web application, which, surprisingly, handles