I asked it without thinking.
We were deep in user stories. Claude had just recommended three email notifications — FK deadline approaching, report overdue, broken calendar connection. All of them reasonable. All of them real things that would cause problems if missed.
“is this overkill for MVP?”
I’ve asked that question hundreds of times. Sprint planning, product reviews, the first meeting with a new engineer who arrived with a full feature spec. It’s a reflex. You build it in startups, when the cost of building the wrong thing is a week you don’t get back.
I didn’t expect to need it here.
Claude’s answer:
“Honest answer: partially. The FK deadline and overdue report emails are not overkill — missing a deadline means no payment. The broken calendar connection email is overkill for v0.1. The in-app warning is enough for now.”
Two yes. One deferred. Reason given for each.
That was it. The session kept going.
Why AI tools over-engineer — and why that’s not a flaw
Claude suggested all three notifications because all three are correct. They’re the complete answer to “how does the guardian know something needs attention?” An engineer briefed on the same problem would propose all three too.
But completeness and MVP scope are different things.
AI tools don’t have a launch date. They don’t have a team of two working evenings, or a roadmap with three items on it. They’ll propose the full solution every time — because they have no reason to hold back. There’s no budget to protect. No sprint to fit into. Thoroughness has no cost for them.
Knowing when to stop isn’t something a language model can learn from training data. It comes from somewhere else.
The question that costs nothing
The product development models I’ve worked with for years — writing the press release before the feature, working backwards from the user, pressure-testing scope before a line of code gets written — they don’t disappear when you’re building alone. They just go quiet.
The instinct fired anyway. I’m not sure it would have if I hadn’t built up the muscle.
For a non-developer saying yes to everything Claude suggests: there’s one question worth asking before you accept a recommendation. Not a technical one.
What problem does this solve for the user — and does it need to exist right now?
You don’t need to know how the code works to ask it. You just need to ask it before the thing gets built.
Two notifications are going into v0.1. One is waiting. The app is slightly smaller than it would have been, and that’s the right size for now.