Beacon API Client

Keyboard-first API client for macOS — free today, no account

Visit Website
August 17, 2026 Our privacy page opens with the fact that costs us the sale

Second post from us here; the first was the what-we-shipped one. This is about a decision we are fairly sure loses us installs, and would make again.

Beacon's privacy page opens by telling you that the app reports anonymous usage data, that it is on by default, and which switch turns it off. For a page people open hoping to be reassured, that is the worst available opening and the only one we could defend.

Three sentences on that page cost us the friendly version:

- Anonymous usage reporting is on by default, and one switch in Settings → Privacy stops it uploading. - That switch stops the upload, not the recording. The app carries on counting usage and capturing errors on your machine — it just sends none of it. - Nothing already sent is removed by switching off; there is no delete path for it in the app, which is why the switch is worth flipping before rather than after.

The sync section has the same shape. Cloud Sync is opt-in, and its encryption is selective and field-level rather than whole-document: variable values you flagged as secret, auth credentials, credential headers and URL userinfo are encrypted before upload, while names, URLs, non-credential headers, bodies and scripts go up as plaintext — so a token pasted into a body or a script is not protected. The two-word phrase every reader scans that paragraph for is not available to us, and those qualifiers cost us the short version everywhere else: the FAQ, the feature list, every reply about it. That price is charged every time, not once.

What it costs, in the terms this forum cares about: put that page beside a competitor's row of green ticks and ours reads as the riskier product. A feature comparison rewards whichever product's copy is vaguer, and honesty loses that table. We cannot tell you what it cost in installs, because we don't publish install numbers and we are not going to invent a counterfactual. Revenue is still $0, so there is no conversion story to spin in either direction.

Why we take the trade anyway: Beacon is an unsigned indie app you download from GitHub and then point at the credentials you use for work. We cannot buy our way into your confidence and we have no corporate backer to lend us any. A page whose sentences survive being checked is the one thing we have that a better-funded competitor cannot also claim — and it only works if the least convenient paragraph is in it.

The long version, including the parts that still break: The page itself, in full:

https://beacon.quizuncle.com/privacy/

The question: if you have led with the unflattering default instead of burying it in a policy page — did it cost you anything you could actually measure, or only the version of the pitch you wanted to give?

4 Comments

  1. 1

    I think the interesting thing to measure here isn't just whether the privacy page hurts installs, but whether the people who do install are more likely to trust and retain the product because of it.

    You could probably learn a lot by looking at the install → activation → retention numbers before and after making the privacy details this prominent. The honest version may reduce some installs but improve the quality of the users who stay.

  2. 1

    Why do you think that loses you installs? A lot of people don't read Privacy Policies and a ton of websites collect anonymized data via FB pixels, GA, or web apps that use tools like PostHog.

    If you do think it is costing users then remove the summary at the top. Having it is just a "nice-to-have" convenience so removing it is not "burying" it or being sneaky.

  3. 1

    Interesting that you're bringing back an older product rather than starting from zero. Curious whether the relaunch is attracting mostly existing users or entirely new ones.

  4. 1

    Isn't posting twice about the same product self-promotion?" — Two posts, ten weeks apart, both carrying something that is not a pitch… Be in other people's threads in between, or the second post arrives from a stranger who only turns up to talk about himself.

August 17, 2026 We built a keyboard-first API client for macOS. Revenue: $0, and here is what it isn't.

We build Beacon. It is a desktop API client for macOS, the current build is v0.2.2 (published 2026-08-13), and the numbers are the ones in the title: no revenue, no paid tier yet, no funding, one person. We don't publish install numbers.

Here is the honest version of what it is and what it costs.

The itch. Composing an HTTP request is a small thought — a method, a host, a path, one header, a bit of JSON. Expressing it took longer than having it in every client we used, because the steps live in different places: a dropdown for the method, a field for the URL, a tab for the body. The cost is not milliseconds, it is the thread. You look away to find the method selector and the request you were holding has to be picked up again when you look back.

What we built instead. The URL bar is the way in, and it classifies what you type. There are six modes it detects for you — URL, method-prefix, curl, > commands, {{variable}}, search — and no mode switcher, because the only thing worse than a mouse round-trip is a mode you have to declare first. Type post api.example.com/orders and method-prefix mode sets the method and strips the prefix when you send. Paste a curl command straight into the URL bar and it fills the tab, ready to send — the Send button relabels itself Import and never fires the request, so sending is a second, deliberate keystroke. That is the point rather than an oversight: pasting somebody's curl line out of a bug report and having it execute against whatever host it names is a thing we would rather the app never did to anyone.

Where it stops, because you would find out on day two. The keymap binds sending, the two Omnibox modes, tabs, focus-cycle, environments, save, help and the digit keys for the side panels. It binds nothing for the request-builder fields themselves — method, URL, params, headers, auth, body. "Keyboard-first" describes the way in and the way around, not every field in the app, and we would rather write that sentence than have you discover it.

The unflattering column, in the site's own words, because paraphrasing these is how they get softer:

  1. Not currently. Builds are published for macOS only — Apple Silicon and Intel, both with every release — and there is no committed date for other platforms yet.

  2. Beacon is an indie project without a paid Apple Developer subscription, so it is not notarized, and macOS shows its standard warning for any unsigned app from the internet. The install script and Homebrew both clear that for you, so most people never see it. Only the manual DMG route hits it — one xattr -cr /Applications/Beacon.app in Terminal and it opens normally from then on.

  3. No — the app's source is private right now. The compiled builds are free and public on GitHub (quizuncle/beacon-releases), but the source itself isn't open at this point.

  4. Free today. A pro tier is planned; nothing that is free now will be moved behind it.

That last quote is the whole business model so far, and it is deliberately narrower than the sentence we would like to write. The subscription in the second quote is $99/year, which is a real line item when revenue is $0 — that is the actual reason the app is unsigned, and we would rather say so than let it read as a philosophy.

There is no signup funnel either: an account is optional, and everything but Cloud Sync and publishing a share works without one. So the metrics we could report are mostly zeroes, and the one we are not reporting is the install count.

The longer version of the reasoning is on the blog:

https://beacon.quizuncle.com/blog/keyboard-first-api-client/

The question we actually want answered: for anyone who shipped a free desktop tool and later added a paid tier — what decided which side of the line each existing feature landed on? We have committed to not moving anything that is free today, which means the pro tier has to be built rather than fenced off, and we would like to hear from someone who has done it in that order.

1 Comment

  1. 1

    If you want to try it, the download page on the site lists three routes, in the order we would take them: an install script, Homebrew, or the DMG. The script's source sits next to it so you can read the thing before you run it — that is the order we would want them offered in, rather than the shortest one first.

    Requirements are macOS 12 (Monterey) or later, on either an Apple Silicon or an Intel Mac; both builds ship with every release.

    IH will not let this account post links yet, so the exact commands are in a follow-up once it does.

About

Composing an HTTP request is a small thought that took longer to express than it took to have. I build Beacon on my own to make the URL bar the way in.