Embracing the 3-Month Rule: A Framework for Lean Development in Startups

In the startup world, the well-known mantra from Paul Graham, “Do things that don’t scale,” often raises eyebrows. While the advice is clear, translating it into practical coding strategies can be challenging. After eight months of developing my AI podcast platform, I’ve adopted a straightforward guideline that’s worked wonders: every unscalable solution gets a three-month trial period. If it proves its worth during that time, I’ll invest in a more robust implementation; if not, it gets shelved.

The Reality of Technical Decisions in Startups

As engineers, we are often trained to prioritize scalability right from the outset. Terminology such as design patterns, microservices, and distributed systems are frequently thrown around—concepts that cater to platforms expected to handle vast user numbers. Yet for startups, this approach can frequently morph into costly indecision. Code optimized for users who aren’t even onboard can lead to wasted resources. My three-month rule compels me to produce straightforward, even “imperfect,” code that gets deployed, allowing me to truly understand user needs.

Current Infrastructure Hacks: Strategic Decisions or Mistakes?

1. Centralized Virtual Machine (VM)

I run the core components of my platform—database, web server, background jobs, and caching—on one $40/month VM, relying on manual backups. While this setup may seem a bit reckless, it has been enlightening. Within just two months, I gained insights into my resource usage that would have otherwise required extensive planning documents. My “AI-heavy” application only peaks at 4GB of RAM. The complex Kubernetes architecture I almost implemented would have led me to manage empty containers instead of real demands.

2. Hardcoded Configurations

My configuration is simple:

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

Everything is hardcoded, which simplifies tracking and retrieval. While it requires a full redeployment for any changes, the payoff has been significant. In three months, I made only three changes, saving me from the immense overhead of building a dedicated configuration service.

3. SQLite in a Multi-User Environment

Yes, my application runs off an SQLite database. Surprisingly, it’s handling user demands remarkably well, even with 50 concurrent users.