A relevant conversation is a starting point, not a customer

GODFREY LEBO — Fri, 02 Oct 2026 07:12:28 +0000

Finding a thread with the right keyword can feel like progress. It is only useful if the person is describing a problem your product can actually help with.

That distinction is central to what I am building with Trackshon. It helps founders find public conversations, prepare replies using their product context, and record what happens next. You review and post the reply yourself.

Here is the small qualification checklist I would use before responding to any suggested conversation:

Problem: what is the person trying to accomplish?
Fit: which part can the product help with today?
Timing: is the conversation still active or useful?
Permission: do this community's rules allow the kind of reply you are considering?
Contribution: can the reply help even if the reader never clicks a link?

If those answers are weak, a polished pitch will not fix the mismatch.

The next step is to record an outcome without overstating it. A view is not a signup. A signup is not an active user. An active user is not a paying customer. Tracked links and manually recorded events can help connect activity to outcomes, but they are not perfect attribution.

Trackshon also includes a website audit for search engines and AI assistants. The purpose is to give someone who finds you a clearer destination, with concrete improvements to consider. It is not a guarantee of search ranking or AI citations.

The product is in early access. The site has an interactive walkthrough, with illustrative conversations and people explicitly labelled. There is a free preview; conversation scouting and daily monitoring are paid features.

Try the walkthrough: https://www.trackshon.com/

The feedback I want most is specific: if a suggested conversation is a poor fit for your product, what did the match misunderstand?

Disclosure: I am Trackshon's founder. This article was prepared with AI assistance using the live product and project documentation.

Before an LLM request leaves your app, inspect what it contains

GODFREY LEBO — Fri, 02 Oct 2026 07:03:58 +0000

A support message can contain two different things: the task you want an AI model to perform, and details the model does not need to perform it.

“Draft a reply about a delayed delivery” is the task. A customer's email address in that same message may be unnecessary context.

I am building Sether around that boundary. It is an open-source library that replaces detected sensitive values with stable tokens before text goes to an LLM. Your application keeps the mapping and can restore recognized tokens in the response.

The useful question is not “did we add a privacy tool?” It is “what actually left the application?”

A practical evaluation has four parts:

Start with fictional data. Create messages containing values your workflow encounters, plus ordinary text that should remain untouched.
Inspect the redacted request before sending it anywhere. Count missed values and unnecessary replacements separately.
Check task quality. Can the model still draft a useful response with the reduced context?
Check restoration. If the response preserves a recognized token and the mapping is available, restore it. Test altered tokens and missing mappings as failure cases too.

Streaming adds another case: a value may be split across chunks. Include that in your tests rather than relying only on complete strings.

The token mapping also deserves attention. Decide which request or user owns it, who can read it, and how long it should exist. Redacting the outbound prompt is only one part of the application's data flow; logs, traces, attachments and downstream tools need their own review.

Sether is not a promise that every sensitive value will be detected, and installing it does not establish regulatory compliance. Detector selection, configuration and workflow evaluation matter.

The released library is MIT licensed. The hosted gateway is not part of this release.

Source and installation instructions: https://github.com/raeven-co/sether

If you build AI support or internal-assistant workflows, which test would you want a redaction library to pass before you put it between your app and a model?

Disclosure: I am Sether's founder. This article was prepared with AI assistance using the project's documentation.

DEV Community: GODFREY LEBO

A relevant conversation is a starting point, not a customer

Before an LLM request leaves your app, inspect what it contains