Running on real hardware — prototype stage

One API.
Any restaurant hardware.

A ProxyNode is a tiny device on your own network that turns one HTTP API into raw printer, drawer, scanner, and scale protocols. No drivers, no cloud in the path — receipts keep printing when the internet doesn't.

I build POS software

Stop writing printer drivers →

Integrate one JSON API. Test in CI against a digital twin — no hardware.

I run a restaurant

Escape the hardware tax →

Use the printers you can afford with the POS you already have — offline-proof.

Get early accessSee how it works
POST http://proxynode-7f3a.local/print
{
  "lines": [
    { type: "text", value: "Table 4", bold: true },
    { type: "cut" }
  ]
}
node online · paper OK · drawer closed — read live over DLE EOT

The problem

Restaurant hardware is a fragmented mess — and your software pays for it.

Decades of incompatible peripherals sit between cloud POS software and a working front counter. Today, someone writes glue code for all of it.

Driver hell

Every printer, scale, and scanner speaks its own dialect. Supporting them means shipping and maintaining dozens of brittle, platform-specific drivers.

Vendor lock-in

Legacy POS contracts only talk to expensive, proprietary hardware. Swapping in cheaper gear means the whole system quietly stops working.

Hardware churn

A restaurant replaces a Star printer with an Epson and suddenly your software needs a code change. Multiply that across every location.

How it works

Two layers. Your software only ever touches the top one.

Commands flow down; status flows back up. The POS talks to a single API on your own network and stays completely insulated from the hardware underneath. No broker, no round trip to a data centre.

  1. 1

    Local API

    ProxyNode on your LAN

    Your POS calls one JSON API at proxynode-<id>.local — or streams raw ESC/POS to :9100 like any network printer. An ESP32-S3 turns those commands into raw bytes.

  2. 2

    Peripherals

    The hardware you already own

    Printers, cash drawers, scanners, scales. USB, serial, or Ethernet.

Later, optionally: a hosted layer for reaching nodes off-site, fleet management, and OTA updates. Local printing never depends on it — and keeps working if your internet is down.

Why believe it

Claims a prototype can actually back up.

Everything below exists in the repository today and runs in CI — not on a slide.

Real hardware, end to end

An ESP32-S3 enumerates a real USB thermal printer, prints, cuts, and reads live paper, cover, and drawer state over DLE EOT. Chips and a printer on a bench — working.

Zero-integration path

A POS that already prints to a network printer just points at the node's :9100 port. It works with no code change — including the status polling.

A digital twin, byte for byte

The simulator is a LAN service that mirrors the firmware exactly: same API, same :9100 port, same telemetry — plus fault injection. Integrate before hardware exists.

Conformance, not vibes

One suite runs identically against the twin and a real node. "Works against the simulator" actually means something.

Honest status reporting

When a printer can't answer a status query, the node's driver layer models the reading as known: false instead of inventing "no faults" — "paper is fine" and "I can't tell" never get conflated.

Tunable without a reflash

Per-printer quirks — cut clearance, print width, USB pacing — are runtime config over PUT /config, persisted on the device. Dialing in a printer is a curl.

Hardware variants

One core board. Populated for the station it lives at.

The ESP32-S3 compute module stays constant; connectors change per SKU. Same firmware, same API — different ports.

Front counterwifi

Wi-Fi Node

Drives a standard USB receipt printer over Wi-Fi. The everyday workhorse.

  • USB receipt printer
  • Cash drawer (via printer)
Host standserial

Legacy Serial Node

Speaks RS-232 to the older scales and pole displays nobody wants to replace.

  • RS-232 scale
  • Pole display
Bar / takeoutstation-hub

Station Hub Node

One node, three ports — printer, scanner, and scale on a single station.

  • USB printer
  • Barcode scanner
  • USB scale
Kitchen linepoe-ethernet

PoE Ethernet Node

Data and power over one Cat6 run, for deep kitchens where Wi-Fi gives up.

  • USB kitchen printer
  • PoE — no wall wart

Protocol emulation

Look like the printer your POS demands. Use the one you can afford.

A node can run entirely on the local network and present itself as the network printer a legacy system expects — then drive cheap, generic gear behind it.

TCP :9100

Working today

Raw ESC/POS emulation

Listens on the standard raw-print port, accepts the bytes a legacy POS sends to a network printer, and forwards them to the connected hardware — answering DLE EOT status queries so the POS gets real paper, cover, and drawer state, not a guess.

HTTP · vendor protocols

On the roadmap

Vendor endpoint emulation

Planned: exposing vendor-style print endpoints (such as ePOS-Print XML), parsing the incoming job, and translating it to raw ESC/POS for whatever hardware is actually connected. Not built yet — it ships when it's real, not before.

Built the right way

Emulation is written from scratch against publicly documented specs — no proprietary code or firmware is copied. Nodes ship with a generic identity; compatibility behavior is something the operator explicitly turns on per node. You configure the tool; the tool is not deceptive by default.

Open core

The protocol is open. The moat is doing it well.

The wire protocol, the firmware, the digital twin, and the conformance suite are being opened — free to run, free to build on, local-first forever.

Free forever

  • · The local API and wire protocol, as a public spec with a conformance suite
  • · Node firmware — flash your own ESP32-S3 if you like
  • · The digital twin and dev tooling, for CI and integration work

Paid, later

  • · Assembled, supported hardware
  • · A fleet control plane — monitoring, remote config, OTA across sites
  • · ISV licensing, white-label builds, and conformance certification

The pattern is proven: open local data plane, paid management on top. A print job never needs our servers — that's the point. Read the full open-source stance →

Where we are

Building in public, one honest phase at a time.

No manufacturing claims we can't back up. The bench phase is complete — real chips driving a real printer — and the pilot phase is underway. The full roadmap, including what is deliberately not built yet, is public.

  1. Phase 0 · Bench validationComplete

    Done: an ESP32-S3 drives a real thermal printer end to end — USB enumeration, print, cut, live paper/cover/drawer status over DLE EOT — plus :9100 emulation, runtime config over the LAN, a digital twin, and a conformance suite that runs against either.

  2. Phase 1 · PilotIn progress

    Now: the remaining transports (serial, Ethernet printers) behind the same driver seam, headless provisioning, and a handful of dev-board nodes running local-only in pilot restaurants.

  3. Phase 2 · Custom PCB

    Purpose-built four-layer boards per variant, reliability hardening, and a developer SDK.

  4. Phase 3 · First production run

    A commercial manufacturing run, certification, and emulation profiles for direct-to-restaurant sales.

Full detail, including what's deliberately deferred: the roadmap.

Locked into hardware you hate?

We're looking for pilot restaurants and integrators. Leave an email and we'll reach out as nodes come off the bench.