The 10-second receipt that became a product
ReceiptKit didn't start as a product. It started as a problem in a two-store hardware shop — receipts that took 7 to 10 seconds to print, on every single sale. This is how solving that properly turned into ReceiptKit.
A real business, a real printer, a specific ask
Family Hardware is a two-location hardware retailer running Star Micronics thermal printers and a custom browser-based POS. The POS lives in the browser and on mobile devices — which is exactly where the trouble starts, because a browser can't talk to a local printer directly.
A cloud printing solution had to do two things at once. The receipts couldn't be plain text; they had to be fully custom designs with images, logos, and custom fonts. At the same time, printing had to feel instant. Those two goals pull against each other, and every cloud approach we looked at made you choose between them.
Three approaches, three dead ends
We worked through the options that existed at each point in time. Each one taught us something the next had to fix.
Star CloudPRNT (polling)
The standard cloud-printing approach at the time: the printer polls a cloud endpoint every ~5 seconds for queued jobs. We built a cloud print server around it.
It worked, but only barely. Every sale ended with the cashier and customer standing there waiting on the receipt, usually for 7 to 10 seconds and sometimes longer, since the delay depended on where the printer landed in its polling cycle and how long the receipt took to render. Employees complained about it constantly.
Serverless + queue DB
We moved the print server to serverless edge functions and optimized the image-to-binary conversion. That got us to ~5–7 seconds and removed a standalone VM.
Faster and simpler to run, but the cost didn't scale. The printer still polled every 5 seconds, so we paid for a serverless invocation around the clock whether or not anyone was buying, roughly $5 to $10 per printer a month. Fine for one store, unworkable across many.
CloudPRNT Next (on-printer MQTT)
In July 2024, Star finally shipped CloudPRNT Next — a real-time path that pushes jobs to the printer over MQTT instead of polling. The catch: it didn't work with the older mC-Print3 models, so it meant buying all-new printer hardware that supported the protocol. Even then, text-only receipts were fast — but anything with a logo, barcode, or QR code took 5+ seconds, and got worse with more image data.
This time the problem wasn't something we could optimize our way out of. We worked directly with Star Micronics to trace the slowdown, and both sides landed on the same answer: the printer hardware simply can't process image data fast enough over MQTT. There was no path around it, which made it a dead end we'd have had to accept.
Route through the cloud — render and print locally
The cloud was never the problem — ReceiptKit needs it to trigger and coordinate every print. The problem was making the printer wait on it: polling a cloud endpoint for jobs, streaming a fully-rendered image across the internet on every sale, or pushing the work onto the printer itself and running into conversion or processing limitations on the printer hardware.
So we split the work. A print still routes through the cloud — but instead of shipping a rendered image or making the printer poll, the cloud sends a tiny message to a bridge on the store's own network — just the JSON print data for that sale, a few hundred bytes, not a rendered image. The bridge combines that data with the template it already has cached, renders the receipt locally, and streams it straight to the printer over TCP/USB, so it starts printing the instant the data reaches it. The cloud keeps doing what it's good at — coordinating prints and managing templates — while the heavy work happens inches from the printer.
The engineering that keeps it fast
Instant prints and rich, custom designs usually pull in opposite directions. A few deliberate choices let us have both.
An SVG-shaped template
Receipts are designed in a visual drag-and-drop editor. The template is static SVG plus element definitions; a fast text transform injects the order's JSON to produce a real SVG that converts to the printer's binary format. SVG because browsers render it natively — so the editor previews accurately — and because it converts to other formats extremely cheaply.
A 50× faster font path
General-purpose rasterizers load system fonts on every render — about 600ms each time. We do the font-to-outline conversion ourselves instead, and the bridge caches fonts locally, loading only the ones a template actually uses. That cuts render time to roughly 12ms — the difference between custom fonts being a nice idea and being free.
Rust where it counts
On the Raspberry Pi bridge, the hot rendering path is a native Rust binary for maximum speed. The desktop bridge reuses the exact JavaScript generator the website runs.
Making template design easier
To take the work out of designing a template, we added AI authoring paths on top of the same rendering pipeline — so you can get to a working, editable receipt without starting from a blank canvas or touching code.
From 10 seconds to imperceptible
End-to-end print time went from 7–10 seconds to under 100ms — about 40ms on the local network. Roughly a 100× improvement over the production system it replaced, with full support for images and custom fonts, and no per-print polling or compute cost.
It runs Family Hardware every day
ReceiptKit isn't a demo. It's in real production use across both store locations — the same platform you can sign up for. Most tools ask you to be the first one to trust them. This one has already printed thousands of real receipts at a working hardware store.
Print your first receipt in minutes
Design a template visually, install the free bridge, and send a print with a single API call. The same stack that runs a real hardware store.