Recommendation + Tradeoff Beats a Menu Every Time

Pattern I noticed after a week: I'd ask "how should we handle Neon's free-tier compute suspension?" and get back three options with bullet points. A: boot-time keepalive. B: retry middleware. C: boot-time warm-up plus fail-soft JWT verify. Pros and cons under each. Please choose.

I'm asking the question because I don't know the answer. A three-option menu asks me to make a technical call I don't have the context to make. What I want is a recommendation and the main tradeoff, presented as something I can redirect.

Wrote that down.

The rule

In user_working_style.md:

Recommendation + main tradeoff, not a menu. For exploratory questions ("what should we do about X?", "how would you…?"), respond in 2–3 sentences with one concrete recommendation and the key tradeoff. Treat it as something I can redirect, not a decided plan.

Conversations changed shape immediately. Before:

Me: how should we handle Neon's free-tier suspension? Claude: Three approaches. A: keepalive ping every 4 minutes — pros: simple, keeps connection warm. Cons: background noise, may exhaust free-tier compute hours. B: retry middleware on DB errors — pros: no background work. Cons: user-visible latency on first request after idle. C: boot-time warm-up plus fail-soft JWT verify — pros: handles cold start + transient failures gracefully. Cons: more code surface. Which would you like?

After:

Me: how should we handle Neon's free-tier suspension? Claude: Boot-time SELECT 1 warm-up plus fail-soft JWT verify. A keepalive ping would be simpler but would exhaust the free-tier compute budget within a couple of weeks — I ran the numbers. Walk through the math before implementing?

The second is shorter, it's a call I can actually evaluate (I know what "exhaust the compute budget" means; I don't know what "background noise" means), and it has a built-in off-ramp.

Why the tradeoff clause matters

A recommendation without the tradeoff is "trust me." A recommendation with the tradeoff is "here's what I'm choosing and what I'm giving up."

Two effects:

• The tradeoff is the thing I need to evaluate the call. "Would burn the compute budget" told me whether to agree.
• It surfaces how robust the recommendation is. Small tradeoff = recommendation probably right. Big tradeoff = decision worth pausing on.

When I overrode

Once in three weeks. UX question: should Study mode's completion overlay auto-navigate home after 2 seconds, or require a button click?

Claude recommended the button click — less disorienting, gives the user control. I overrode to auto-nav because in practice I was using Study mode on my phone and wanted to chain sessions without tapping.

The recommendation was right for a generic user. I was the first user, and the first user's workflow beat the generic design principle. The tradeoff sentence ("user loses control") told me exactly what I was giving up.

If the answer had come back as a menu, I'd have picked auto-nav without ever knowing there was a principled case for the button click.

File format that's working

**[Rule.]** [When this applies.]

**Why:** [the reason; the more concrete the better]

**How to apply:** [the specific moments when the rule kicks in]

Same shape used for everything in the memory folder.

Takeaways

• For exploratory questions, ask for one recommendation and the main tradeoff. Not a menu of options.
• The tradeoff sentence is what makes the recommendation evaluable. Without it, you're choosing between trust and interrogation.
• Override the recommendation when you know something it doesn't. The point of the format isn't agreement — it's a default to evaluate against.

---

Terms

Neon — A hosted, serverless flavor of Postgres. Pay for what you use, scales to zero between requests. The free tier suspends compute after 5 minutes of inactivity, then warms back up on the next query (a "cold start").

Cold start — The latency that happens when an idle service has to spin back up to handle a request. With Neon's free tier, the first query after suspension takes a few seconds.

Keepalive — A small periodic request (e.g. SELECT 1 every 4 minutes) sent to keep a connection from being closed or a service from being suspended.

Middleware — Code that runs before and/or after every HTTP request. A "retry middleware" would intercept failed DB queries and retry them automatically.

JWT — JSON Web Token. A signed string the frontend sends with every request to prove the user is logged in. The backend verifies the signature on each call.

Memory file — Plain text file Claude Code automatically reads on every new session. Records preferences and lessons so they persist across conversations.