Fae · specimen №07
Bellhop
Printers and scales for web apps, with no one in the middle.
Local printing and USB scale reading for SaaS products: a desktop agent, server libraries, and a licensing backend that stays out of the data path. Labels print with no browser open and nobody logged in.
- Role
- Product design, engineering, protocol design
- Platform
- Web + macOS + Windows + Linux
- Years
- 2026–present
- Built with
- Ruby on Rails · Swift & SwiftUI · WebSockets · Ed25519 · Node & Rails libraries
- Status
- Live
The problem
A web application can't reach the label printer sitting at its customer's warehouse. The existing answers are all compromises: browser print dialogs need a person and an open tab, localhost bridges and extensions die with that tab, and cloud print relays work by receiving a copy of every label you print.
What a developer actually needs is plainer than any of those: print from the server with no browser open and nobody logged in, read the shipping scale on the desk, and never route customer data through somebody else's cloud.
The approach
Bellhop splits the problem in three. A menu-bar agent lives at the desk. A library in the developer's server, Node or Rails, holds the connection to that agent, so print jobs and scale readings travel directly between the two. The third piece, bellhop.dev, only handles licensing and pairing.
That structure makes the privacy claim verifiable instead of contractual. The registrar signs a credential the agent checks offline against public keys baked into its build, so bellhop.dev never sees a print job or a weight, and printing keeps working when bellhop.dev is down. The architecture is the proof, not the promise.
Decisions that mattered
4 entries
Out of the data path by architecture, not policy
Entitlements are enforced locally by the agent from a signed Ed25519 credential; nothing phones home. A privacy policy can change. A system that never receives the data can't.
Agents are counted, pages never are
Plans meter installed agents, not print volume. Per-page pricing makes customers anxious about succeeding: the busier their warehouse, the worse their bill. That anxiety is the competitor's business model, not Bellhop's.
No passwords, anywhere
Magic links and passkeys for the developer's dashboard; a pairing link for the person at the desk. The packer who clicks that link never chose Bellhop and shouldn't need credentials to live with it.
The protocol is a document, not an implementation detail
Flat JSON messages over a WebSocket or two plain HTTP routes, with normative docs, JSON Schemas, and a dependency-free reference server. Where the code and the docs disagree, the code is wrong.
What it does
For the developer
- Node and Rails libraries covering pairing, both transports, redelivery, and renewal
- ZPL, PDF, and raw formats with per-job printer targeting
- Printer capability reporting: options a printer can't honor fail loudly, never silently
- USB scale readings pushed to the server as they happen
- Fleet dashboard for pairing, licensing, and agent status
At the desk
- A macOS menu-bar agent: pairing is a link, not a setup wizard
- One install pairs with several apps, each with its own connection and printers
- Prints with no browser open and nobody logged in
- Errors name the app they came from
Marginalia
Bellhop is the one piece in the catalog made for other developers, and the one designed to go unnoticed: it lives inside someone else's product, and the person at the desk clicks a pairing link once and never thinks about it again. It ships for macOS, Windows, and Linux, with libraries for Node and Rails.
