SharetoBoard
Founder story

My best ideas rarely waited for me to be at my desk.

I built SharetoBoard because the useful thing kept appearing on my phone, in the browser, or halfway through another task—and too often disappeared before it reached the Poppy board where I could actually work with it.

Where it started

I did not need another place to store notes.

I already had notes apps, documents, folders, bookmarks, and AI chats. Storage was not the problem. The problem was that my best source, phrase, question, or half-formed idea often appeared while I was moving between work, family, research, and client conversations.

Poppy worked for the way I think. It gave the mess a visual place to become connected, structured, and useful. But reaching that board from Android took enough steps that the idea could drift—or end up in one more temporary note I would never open again.

So I built the missing layer: a shorter path from the phone in my hand to the board where the work comes together.

What I brought to it

Creator instincts, builder habits, and a security architect’s skepticism.

I have spent more than fifteen years working in cybersecurity, engineering, and architecture. I also create content, build automation tools, and use AI systems in the middle of real work. That combination shapes SharetoBoard: it has to be fast enough to use in a messy moment and disciplined enough to stop when the destination or authority is unclear.

The goal is not more automation for its own sake. The goal is less friction between noticing something valuable and doing something meaningful with it.

How it grew

The same problem had three different entry points.

Phone

SharetoBoard Android captures from the device where ideas and sources are noticed.

Browser

SharetoBoard Chrome captures selected web content. Chrome Pro keeps user-configured Poppy Specialists beside the source.

Agents

Tentaclaw gives MCP-capable agents a controlled route to the Poppy API through first-party skills and six focused tools.

One workflow does not require one oversized product. Android, Chrome, Chrome Pro, and Tentaclaw are connected by what they help you do. Each keeps a separate job and a separate security boundary.

Why security shaped the products

A faster workflow is not worth handing every component the master key.

Working in security taught me to look beyond whether a demo works. I also want to know what can see the credential, where data persists, what happens after a mistake, and whether the system fails safely.

That became a product rule. Chrome Pro works with Poppy chatbot links and never accepts a Poppy API key. Tentaclaw keeps the API key behind a local process, while the client and its skills see only a small set of approved operations.

The public security story stays vendor-neutral because the lesson matters more than a takedown: telling an agent “do not reveal this key” is not a security boundary after the agent can already see it.

Build principles

Short paths. Small authority. Honest status.

User-invoked

Capture and agent operations begin with an explicit user or agent action, not an invisible background workflow.

Fail closed

Ambiguous destinations, unavailable credentials, unsupported content, and unsafe exposure stop with a clear error.

Say what is ready

Beta, private preview, release candidate, and public release mean different things. The status page keeps those differences visible.