At 2 AM, when the pager goes off, there are two kinds of systems. The kind where you read the logs, see the problem, and fix it. And the kind where you first have to re-learn how the system works before you can even start reading the logs. I have strong opinions about which kind I want to be woken up by.

This isn't about laziness. It's about carrying cost: the tax you pay every single day for power you aren't using. Heavyweight tools make you pay it up front and forever. Lightweight tools let you pay as you go.

**vi, not Emacs.** Every server, every container, every rescue shell has vi. It's already there, it starts instantly, and modal editing means your fingers never leave home row. Emacs is a fine operating system — it just lacks a decent text editor. The joke is forty years old and still true: one of these is a tool you pick up, the other is an environment you move into. I don't want to move in. I want to edit the config and get out.

**Caddy, not Nginx.** My entire Caddyfile for most services:

```
example.com {
reverse_proxy localhost:8000
}
```

That's it. HTTPS is automatic — certificates, renewal, all of it. The Nginx equivalent is a server block, a certbot install, a renewal cron job, and a reload you have to remember. I can write the Caddy version from memory at 2 AM. The Nginx version I look up every time, and I've been doing this for years. That gap — between what fits in your head and what requires documentation — is the whole argument.

**Flask, not Django.** A Flask app is functions with decorators. You can hold the entire request lifecycle in your head at once: request comes in, function runs, response goes out. Django is a framework in the original sense of the word — it frames your house. The admin panel is genuinely excellent. Migrations are genuinely excellent. But you've accepted someone else's floor plan, and every future decision gets negotiated against `settings.py`. Most of what I build needs a shed, not a house. Flask lets me build the shed.

**Redis Streams, not Kafka.** Kafka is a distributed system that happens to move messages: brokers, partitions, consumer groups, replication factors, and a ZooKeeper (or KRaft) cluster to coordinate the coordinators. Redis Streams is `XADD` and `XREAD` on the Redis you're already running. Now here's the honest question, and I want you to answer it out loud: do you need replayable, partitioned, exactly-once event sourcing across twelve teams — or do you need a durable queue? Most teams need a durable queue and buy a distributed system.

The heavyweights aren't *wrong*. Kafka at LinkedIn scale is load-bearing complexity. Django's ORM and admin for a fifty-model CRUD app are load-bearing. Nobody serious thinks Redis Streams replaces Kafka at that tier. The error is buying the tier before you have the problem — mistaking someone else's operational necessity for your architectural mandate.

So here's the decision rule the lightweight gospel usually skips: **name the failure.** Before adopting the heavyweight, write down the specific, concrete failure the complexity prevents. Not the category — the incident. "We need Kafka" is a vibe. "We need to replay six months of order events to rebuild projections after a bad deploy, and we do this quarterly" is a requirement. If you can't name the failure, you're buying insurance against a risk you can't describe, and the premium comes due every day in upgrades, CVEs, and on-call burden.

And the 2 AM test: if you can't debug it at 2 AM without opening the docs, you don't own it. It owns you.

Nobody ever got paged because their tool was too simple.