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:
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.
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.
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.
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.
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.