The counter hardware nobody plans for

The demo runs on a laptop; the shop runs on a strip of paper the width of a palm. At the counter the same system meets four devices that each impose a constraint it cannot argue with: a printer that is not a page, a scanner that is a keyboard, a drawer that opens through the printer, and a tablet configured like someone's phone. Each carries one question, and the answer has to exist before the code, not after the first customer waits.

Why does the receipt come out shrunken?

Because the receipt and the invoice are two documents, and the build treats them as one at two sizes. An invoice has a page: header band, columns, customer address, tax breakdown, totals on the right. A till roll has a line. Print the page on the line and the totals are clipped or the type stops being readable.

The question before the build: at which point does a customer stop needing a receipt and start needing an invoice, and who decides which prints? Then ask the device: text or image? A printer fed an image has the driver turn letters into dots, so small type loses its edge and the numbers print grey; text with size and bold commands stays sharp and prints faster. Design the receipt as its own layout — item lines, quantity, total, payment method, a lookup number — and let the invoice live elsewhere.

Why does the scanner type instead of pasting?

Because that is what it is: a keyboard. A handheld scanner identifies itself as an input device, types the digits and sends Enter. Nothing in that sequence knows where the cursor is standing.

Two failures follow. Focus: the cashier scans while the cursor sits in the discount field, and a barcode becomes a discount. Speed: the digits arrive faster than a field written for a human, so autocomplete fires on the second character, opens a list, and swallows the rest.

The question is not whether the scanner works, but what the field does with thirteen characters arriving in a burst: it should collect them, wait for the terminator, then dispatch once. And before the catalogue is built, ask whether the barcode carries a price or a weight; a scale label does, a product code does not.

How does the cash drawer open?

Through the printer, usually. Most drawers have no driver: they plug into a port on the receipt printer and open when a control pulse is written into the print stream. Opening the drawer is a print job, and it fails like one.

Ask what happens when the printer is out of paper, jammed or switched off, and a customer wants to pay cash. If the drawer cannot open, the sale cannot finish. Some drawers have a key: a fallback for a power cut, not a design for every second sale. Record each opening with a user and a reason; otherwise a shortfall at closing has no explanation.

Why does the tablet sleep at the wrong moment?

Because it was configured as a personal device: screen timeout, auto-brightness, a notification shade, a system that updates itself mid-morning. The cashier's finger is on the payment field and a dialog slides over it.

These are settings, but they belong to the deployment, not the shop's staff. Pin the screen, stop it sleeping on charge, hide the shade, keep the browser in front, and write down what an update may reset, because one will. A kiosk mode set up by hand on one tablet is a favour with an expiry date.

What happens to the till when the connection drops?

This is the question that decides the other four. A till that cannot sell while the line is down is not a till; it is a window onto a system that lives somewhere else. In a shop on a mobile connection, "down" is an ordinary afternoon.

Three questions, in order:

• Can a sale be recorded with no network at all, and does the receipt still print?
• Does the local record carry what reconciliation needs: its own number, a timestamp, the lines, the total, the payment method?
• When the link returns, in what order do the waiting sales post, and can a re-send create a second sale?

If the answer to the first is no, the rest does not matter. Offline brings a second decision too: the price list on the device is a copy, and a copy ages. How stale may it be before the shop stops selling, or reads the shelf label?

Which question belongs to which device?

Device	Ask before the build	If it is skipped
Receipt printer	Text or image, and what paper width?	Grey totals, or a page clipped to a strip
Scanner	Keystroke burst, or one paste?	Digits in the last field that had focus
Cash drawer	Opens only through the printer?	A cash sale stuck behind a paper jam
Tablet	Who owns the screen settings?	It locks with the customer's card in hand

In what order do you settle this?

1. Stand at the counter for one sale and list every device touched, in order, and who touches it.
2. Print an actual sale on a metre of the real receipt paper before designing anything.
3. Scan a real barcode into the real field, and watch where the characters land.
4. Switch the printer off and try to open the drawer.
5. Run a sale, cut the connection mid-sale, and finish it.
6. Write the offline rule: what may be sold, at which prices, with which numbering, and what happens to a sale that arrives twice.
7. Put the device list in the specification, with a named person responsible for each, settings included.

Where this goes wrong

• The receipt is the invoice, scaled down. Columns collapse, totals wrap, and the sale is retyped into a book at closing.
• Printing goes through the browser. A print dialog is a page preview: margins, headers and the paper size chosen by whoever installed the driver all vote.
• Offline means "queue the requests". Without a local number and a timestamp, sales post in the order the connection recovered, and the day's takings arrive twice or not at all.
• A second printer for invoices appears at the back office, configured once, on one machine, by someone who has left.

What this does not cover

It does not name printers or price them: the right device depends on the counter and the budget in front of you. The legal side is out of scope too: some jurisdictions require a certified fiscal device, reachable only through a protocol that decides what a receipt may contain. Check that rule before the layout is drawn.

We build counter software around the hardware already on the desk: two documents instead of one, a scan that lands in a single field, a drawer that opens when it should, and a till that keeps selling when the line goes down.