The Three-Month Framework: A Practical Approach to Non-Scalable Programming

In the world of tech startups, the phrase “Do things that don’t scale,” often attributed to Paul Graham, is frequently cited. However, much less attention is given to how this advice translates into effective programming practices. After spending eight months developing my AI podcast platform, I have created a straightforward framework: every non-scalable hack I’ve implemented receives a three-month lifespan. At the end of this period, it either demonstrates its worth and is integrated into the platform properly, or it is discontinued.

As engineers, we are typically conditioned to focus on creating scalable solutions from the outset. We’re drawn to intricate design patterns, microservices, and distributed systems—architectural masterpieces that can accommodate millions of users. Yet, such thinking often reflects the mindset of larger corporations rather than the realities of a startup environment.

In my experience, coding for scalability early on can often amount to nothing more than costly procrastination. We find ourselves optimizing for future users that may never materialize and addressing challenges that could potentially fade away. My three-month rule encourages me to develop simpler, straightforward, and sometimes “imperfect” code that actually gets deployed and provides insights into what users genuinely need.

Insightful Infrastructure Hacks

Let’s delve into my current infrastructure decisions that might seem unconventional but have proven to be quite effective:

1. Unified Computing on a Single VM

For just $40 a month, I have consolidated my database, web server, background jobs, and Redis onto a single virtual machine. While this means zero redundancy and manual backups to my local storage, the benefits are significant. This setup has allowed me to ascertain my actual resource requirements far better than any capacity planning document. My AI-centric platform peaks at only 4GB of RAM, and I’ve learned that the complex Kubernetes infrastructure I almost implemented would have merely managed empty containers.

When the system does crash—something that has happened twice—I receive genuine data about the technical failures. And surprisingly, they seldom align with my initial expectations.

2. Hardcoded Configuration Simplifies Changes

My coding style features hardcoded constants for settings like pricing and user limits:

python
PRICE_TIER_1 = 9.99
PRICE_TIER_2 = 19.99
MAX_USERS = 100
AI_MODEL = "gpt-4"

This design eliminates the need for configuration files and environment variables; changes necessitate a redeployment. The advantage