Automated kitchen printing for delivery orders on Clover POS terminals

Context

Inside the Checkmate integrations organization, Clover — one of the most widely used POS platforms in US restaurants — had a gap that sat downstream of an otherwise-working integration. Delivery orders from DoorDash, UberEats, and similar marketplaces were already landing correctly on the terminal; a separate order-injection integration handled that side. What happened after the order arrived was this project's problem, and it went unsolved right up until the moment it mattered most.

Challenge

On Clover, the order appeared on screen — and then nothing came out of the kitchen printer. Someone had to notice and press print manually, during a dinner rush, which is exactly where orders get lost and the customer usually finds out before the restaurant does. It couldn't be fixed from the cloud: Clover only allowed printing from software running on the terminal itself, so the one route to the kitchen printer ran through code installed inside a locked-down, embedded-style device with no Google Play Services and no remote print API.

Approach

• Built a small, near-headless Android agent distributed through the Clover App Market: a merchant installs it once and never opens it again — from then on, an incoming order signals the terminal and the agent prints it to every configured kitchen printer, unattended, in seconds.
• Replaced the missing default Android push mechanism — Clover terminals ship without Google Play Services — with an independent transport holding its own persistent connection, with automatic recovery after reboots, app updates, and network loss.
• Designed for zero-touch field deployment: restaurant staff install it themselves with no IT support and no way to check from outside whether it worked, so the app became one screen with zero inputs — even printer selection reused the configuration the merchant had already set up on Clover.
• Made failure loud instead of silent: the agent sounds an alert before attempting to print, and a remote diagnostic trail tells support exactly which stage failed on a specific merchant's terminal, without a site visit.
• Owned the full lifecycle — submission, signing, and release into a controlled app marketplace — across multiple releases over nine months of active development.

Key decisions

• Zero-input design over documentation — with no IT support or device access at any of the 100+ locations, removing every decision point at setup mattered more than explaining one.
• Alert before failure, not after — printing failures are invisible by nature, so the agent was built to cue staff proactively rather than rely on a customer complaint to surface the problem.
• Built to be deleted — the agent was scoped as a bridge over a gap expected to close, not a permanent product; when Clover shipped its own print API, retiring it fleet-wide cost a single backend change, no migration or rewrite.

Outcomes

100+ restaurant locations ran the agent in production across multiple releases, including field bug fixes — real software carrying real kitchen tickets, not a prototype. When Clover closed the gap itself, the fleet-wide retirement validated the original bet: build small enough to delete cleanly the day the platform catches up.