Build notes

The opt-out that almost got answered with a sales pitch

8 August 2026 · where our own incentives ran into our own consent rules · Founder, Klaros

The other notes here are about defects. This one is not. Nothing broke, no customer was affected, and there is no dead-letter queue to show you. It is about a design that was about to be wrong, caught in the hour it was being written, and it is the least flattering thing we have published, because the reason it nearly happened was that we wanted the sale.

Klaros sells itself inside a WhatsApp thread. Message our number, type pricing, and you get the live catalog as a list with a payment link on whatever you tap. We think that is the most honest demo available: you experience the product by buying it.

It also means our own sales code runs in the same inbound path that decides whether somebody's opt-out gets recorded. That is a genuinely uncomfortable place to put a revenue incentive, and this note is about what we found when we looked at it directly.

Two things that wanted the same message

The pricing matcher is a plain regular expression. It has to be broad, because people do not type the word the product manager chose:

const PRICING_INTENT = /(?:^|\b)(pricing|price list|prices?|plans?|packages?|buy|purchase
                        |subscribe|sign ?up|how much|what does it cost)(?:\b|$)/i;

Now read it as somebody trying to get away from us. "Stop sending me pricing" contains pricing. "Unsubscribe from your plans" contains plans. Both are unambiguous requests to be left alone, and both would have satisfied that pattern on their own.

Why this was not just a rude reply

The obvious harm is embarrassing enough: somebody asks to be left alone and gets a price list. That is the version in the headline, and if it were the whole story this note would be shorter.

The real harm is structural. In the inbound consumer, a message that the sales loop has handled deliberately suppresses the consent check that runs afterwards:

// Only the sales loop suppresses the consent check below [...]
const salesHandled = routed.handled && routed.intentId === 'klaros_sales';

// ... later, the consent branch is skipped entirely when that flag is set:
const intent = cadenceChoice || ... || salesHandled
  ? null
  : intentFromButtonPayload(...) || detectConsentIntent(text);

if (intent === 'opt_out') {
  await recordConsentEvent(...);   // the auditable evidence
  await addSuppression(...);       // future sends blocked
  // and every active sequence for this contact is cancelled
}

That suppression is there for a good reason. A prospect who taps a plan or types "plans" is having a structured conversation, and keyword-matching them into an unrelated consent rule mid-purchase would be its own bug. But it means the sales intent holds a door open, and whatever it claims never reaches the code that honours a request to leave.

So if isPricingIntent had matched "stop sending me pricing", three things would have happened and none of them would have appeared anywhere. No consent event recorded. No suppression row written. No sequences cancelled.

The person would have asked to leave, received a price list, and remained fully enrolled in everything they were trying to escape.

The guard

Four lines, and the ordering is the entire point:

const OPT_OUT_INTENT = /(?:^|\b)(stop|unsubscribe|opt.?out|remove me
                        |do not (?:contact|message)|don'?t (?:contact|message))(?:\b|$)/i;

export function isPricingIntent(text) {
  if (typeof text !== 'string') return false;
  const t = text.trim();
  if (!t || OPT_OUT_INTENT.test(t)) return false;   // leaving always wins
  return PRICING_INTENT.test(t);
}

It lives inside the matcher rather than in the caller on purpose. A guard in the caller protects one call site and quietly stops protecting anything the day somebody adds a second one. A guard inside the matcher is inherited by every caller that will ever exist, including the ones written by people who have never read this note.

Worth being precise about the timeline, because it would be easy to imply more drama than there was. This was not found in production. The matcher and its guard were written in the same commit, the one that made the pricing capability real end to end. It never shipped without it.

That is the part we think is actually worth publishing. The dangerous moment was not a deploy. It was the forty minutes of writing a regular expression whose job was to catch as many buyers as possible, on a day when catching buyers was the thing we wanted most.

The same rule, applied four times

One guard in one file would be an anecdote. The reason we are willing to write this down is that the rule is applied independently everywhere a matcher sits near money or enrolment.

The notes-subscription comment is the one we would point at in a code review, because it says the quiet part in a file nobody markets: a false positive there "silently subscribes somebody to marketing they did not ask for. That is a consent failure, not a UX annoyance, and it is the one thing this codebase is least willing to get wrong."

The two shortcuts we did not take

What we have not fixed

This would be a dishonest note if it ended at the tidy part, so here is the thing we found while writing it.

The consent detector only inspects messages of four words or fewer. That limit exists for a sound reason: a long message that happens to contain "stop" is usually a sentence, not a command, and reading "we had to stop the order" as an unsubscribe would be its own consent failure in the opposite direction.

But it means a politely worded departure falls through everything. Run against the live code:

$ node -e "import('./uni-cloud/src/services/klaros-sales.mjs')..."

"pricing"                                     sales=true   consent=neutral
"stop"                                        sales=false  consent=opt_out
"stop sending me pricing"                     sales=false  consent=opt_out   ← guard works
"unsubscribe from your plans"                 sales=false  consent=opt_out   ← guard works
"please stop sending me your pricing emails"  sales=false  consent=neutral   ← nothing recorded

Read that last line carefully. The guard did its job: sales=false, so nobody gets pitched a price list. That is the failure this note is about, and it does not happen.

And then nothing else happens either. Seven words instead of four, and a clear request to be left alone produces no consent event, no suppression row, and no cancelled sequences. The person was not insulted. They were simply not heard.

We are not fixing this by widening the word limit, because the obvious fix creates the opposite error and we would rather state the trade-off than quietly pick a different way to be wrong. It is written down here and in the opt-in evidence page as open, and it belongs to the same unfinished piece of work as the neutral replies in our opt-in funnel that currently resolve to nothing.

What this is actually for

Every platform in this category says it takes consent seriously. It is one of the cheapest sentences in software, and it is usually true right up until the moment it costs a sale.

We cannot prove we take it seriously by saying so. What we can do is put our own revenue on the wrong side of the rule, in public, with the file names attached: the sales loop yields to the word "stop" before it evaluates a single thing it wants, and when we find a place where our listening is worse than our manners, that goes on the page too.

This is the same gap the rest of these notes are about. Digital distance is usually described from the business's side, as the customer you failed to recognise. An unrecorded opt-out is the same gap pointed the other way: somebody told you something true about what they want, and your software did not retain it.

Written 8 August 2026. We append when the facts change. Related: what we found in our own billing, opt-in proof, the belief this comes from, all build notes.