Embracing the Three-Month Rule: A Pragmatic Approach for startups in Software Development

In the technology landscape, many are acquainted with Paul Graham’s famous insight: “Do things that don’t scale.” However, the implementation of this concept in software development remains less explored. After eight months of constructing my AI podcast platform, I’ve devised a straightforward framework: every unscalable solution I employ is granted a lifespan of three months. After this period, I assess whether it has proven its worth and deserves to be developed into a robust solution or if it should simply be discarded.

As engineers, we are often conditioned to prioritize scalable solutions from the onset. We immerse ourselves in complex design patterns, microservices, and distributed systems, all designed to accommodate millions of users. Yet, this approach often aligns more with large corporations than small startups. In the early stages of a startup, the pursuit of scalability can devolve into costly procrastination—optimizing for hypothetical users and addressing challenges that may never materialize. My three-month rule compels me to create straightforward, albeit imperfect, code that is deployable, enabling me to truly understand the needs of my users.

My Current Infrastructure Hacks: Strategic Simplicity

In my journey, I’ve introduced several unconventional infrastructure choices that serve practical purposes:

1. Consolidated Infrastructure on a Single Virtual Machine

I run my database, web server, background jobs, and Redis on a single $40/month virtual machine, without redundancy and with manual backups to my local system.

Why is this advantageous? Within just two months, I’ve gained more insight into my actual resource requirements than any detailed capacity planning document would provide. My platform, which is often dubbed as “AI-heavy,” peaks at 4GB of RAM. The intricate Kubernetes setup I almost implemented would have merely resulted in managing idle containers.

When my system has gone down—twice so far—I’ve received valuable data on what genuinely fails. Unsurprisingly, it’s rarely what I anticipated.

2. Hardcoded Configurations Across the Codebase

Here’s how I handle configurations:

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

Instead of using configuration files or environment variables, I work with hardcoded constants scattered throughout my files. Any change requires redeployment, but this approach has a hidden advantage.