How Blowhorn works
The app, the engine, the extension, the background service, and your organization's store.
Explanation
Understand why: context and trade-offs, no procedures.
Explanations give the reasoning behind Blowhorn's behaviour: how a post travels from the queue to the platforms, where your data lives, who may post as whom, why Blowhorn uses your own Chrome, how it paces itself, why it never repeats a public action, how scheduling works, what runs when the app is closed, and what the analytics numbers mean.
Read these to build judgment. When you want to act, follow a how-to guide instead.
Where your data lives
What stays on your Mac, what lives in your organization's store, and what the extension reads.
Who can post as whom
A credential is permission, a handle is not; a Chrome mapping is identity, not permission.
Why Blowhorn uses your own Chrome
Signed-in Chrome through the extension, APIs where they exist, and never headless.
How Blowhorn paces itself
Human typing and pauses, per-run pace, and why a failure stops the run instead of retrying.
Why Blowhorn never repeats a public action
One click per run, preview first, and what clicked-outcome-not-read means.
How scheduling works
Ten-minute passes, one shared queue across Macs, leases, and the three pause scopes.
What runs when the app is closed
The background service, quitting, keep-running, and how updates reach a closed app.
Why flagged invitations are skipped
A flagged invitation is LinkedIn warning you, so Blowhorn walks away instead of confirming.
What the analytics numbers mean
Measured versus trended counts, what each tile counts, and how fresh the numbers are.
Plans, offline use and lapses
Why plans count profiles and platforms, the 72-hour offline grace, and why dry runs stay free.