CASE STUDY · Tools

Free, stateless, browser-only: the two glincker utilities that did not earn product status became a clean tools hub with full SEO surface and zero backend.

Three small tools, one /tools hub, zero accounts

Shipped: 2026-06-223 min read

PROBLEM

The problem

When we audited the glincker sitemap, two tools came out of the triage without a product home: a profanity filter and a markdown converter. Both are useful, neither has a user state story worth building a backend for, and the market is well-served at every price point including free. Giving them product treatment would have been waste. Killing them entirely would have thrown away real SEO surface area and funnel entry points. A tools hub threads the needle: useful pages, zero operational cost, zero abuse vectors.

APPROACH

Our approach

The guiding constraint was that nothing leaves the browser. No API calls, no server-side logging of user text, no analytics on content. Every tool is pure client-side React: text in, transformed text out, nothing persisted anywhere. That constraint also eliminates the entire backend abuse surface for tools that accept arbitrary user input.

The profanity scanner ships with a 50-word inline word list (MIT-licensed source, documented in the component). The detection logic is a single regex pass with word-boundary anchors. The word list has a clear upgrade path: swap in a maintained library when the bundle budget allows. We did not reach for a dependency in v1 because the inline list covers the common case and keeps the component self-contained.

The markdown converter uses an inline regex parser in v1. The parser handles headings, bold, italic, code blocks, and links. There is a TODO in the component pointing at `marked` as the replacement when we add it to the bundle. The same upgrade-path discipline: ship something useful now, document the ceiling, replace it without ceremony later.

The copy on both tools leads with: nothing leaves your tab. That is a trust signal, not marketing — it is literally what the code does. We kept it in the UI because commodity tool users have been burned by paste-your-text-here services that log inputs.

OUTCOME

What shipped and what we learned.

Three utility pages shipped (Profanity, Markdown, Tools index), zero backend services involved, zero auth required, zero abuse surface exposed. The OG images and sitemap entries derive automatically from the existing registry pattern, so both tools have full SEO coverage from day one.

3Tools shippedProfanity, Markdown, Tools index
0Backend services touchedPure client-side, browser-only
50Profanity word listInline, MIT-ish, upgrade-path documented
Inline regexMarkdown parserv1, TODO swap in marked when bundled
NoneStorage layerUser text never leaves the browser
3OG imagesAuto-derived from the existing registry pattern

STACK

Technology stack

SCREENS

What it looks like.

Tools hub index grid
Tools hub index: two cards, one clear value prop per tool.
Profanity scanner with flagged words highlighted
Profanity scanner: flagged words highlighted inline, count shown.
Markdown converter side-by-side panes
Markdown converter: input left, rendered HTML right, nothing persisted.

MORE WORK

Want to read more case studies?

Back to all work