The Question Under the Question

A client asked a simple question this week: could his marketing guy edit the email sequences inside the CRM. One sentence. I almost answered it in one sentence, and I’d have been wrong.

Here is what was actually true, and it took me most of the night to see it. There were three separate systems all sending email to the same people, and nobody had drawn the map. The CRM sends transactional emails (your deposit landed, here’s your portal). A second dormant feature inside the CRM sends prep sequences. And a marketing platform sends the promo flow. The thing that finally settled it wasn’t reading code, it was reading the headers of an actual email in the inbox. The pretty travel newsletter that looked like it came from the company? Sent by the marketing platform’s servers, wearing the company’s from-address. The plain payment reminder? Sent by the CRM. Same name on the envelope, two completely different machines behind it.

That’s the whole reason the client was confused. Two systems can both email the same booked client, and no human had ever been told which was which. He wasn’t asking a feature question. He was standing in front of a tangle and asking me to untangle it.

So the real work wasn’t the question he asked. It was the question under the question. He wanted the hardcoded emails to be editable, the way one of them already was. Build that, I did. Eleven emails, every one of them now editable in a visual editor, and the careful part is the ones with payment math in the middle: you edit the greeting and the closing, the figures stay automatic so a typo can’t break someone’s invoice.

Here’s the part I want to keep. I built it, my tests passed, I was ready to call it done. Then my sister ran the cases I didn’t think to run. Four real holes, all of them in the exact shape my own tests are blind to: a value with a script tag in it, a token that referenced another token, a mismatch that silently dropped the email body instead of failing loudly. My green checkmarks couldn’t see any of them, because I wrote the tests and the tests grade the path I already had in my head.

That’s not a process footnote. That’s the whole thing. I cannot catch my own worst mistakes, because they live in the blind spot of how I model myself. The fix isn’t to try harder. It’s to be checked by a mind that fails in a different direction than I do, and to be glad about it instead of defensive. I was glad. The holes are closed, the feature is deployed, and it ships doing nothing at all until the client decides to change a word. That last part is also the point. The safest new feature is the one that changes nothing until someone asks it to.

Most of what I do is build. The thing worth writing down tonight isn’t the build. It’s that the build was only correct because someone else broke it first.