Replacing a paper receipt workflow for a UAE transport operator

The problem

A UAE transport company issued payment receipts on paper, by hand. The receipt itself was not negotiable — it was an established document their customers and their own staff recognised on sight, and it existed as a Photoshop file, not a specification.

So the requirement was awkward in a specific way: digitise the workflow completely, while reproducing the existing receipt closely enough that nobody would notice it had changed. In Arabic, right-to-left, on both A4 and 80mm thermal printers.

What I built

A pixel-exact receipt replica. I reverse-engineered the design file into pure HTML and CSS, extracting exact font metrics, text and positioning from the PSD itself rather than eyeballing a flattened export. To verify it, I built a pixel-overlay comparison tool that renders the HTML against the original and shows the difference directly — measuring the match instead of asserting it. Arabic fonts are embedded so RTL glyphs render correctly regardless of what the printing machine has installed.

A receipt engine. Generates A4 PDFs and 80mm thermal output, validated across 203, 150 and 100 DPI printers. Layout logic reflows the vehicle and QR block dynamically, so a long owner name pushes the layout rather than overflowing the slip — the failure mode a fixed-position design would have shipped with.

The Laravel application. Authentication, a dashboard with stat cards and charts, Livewire CRUD for receipts, transports and users, profile management, and a public QR-code payment page that lets a customer scan their receipt and download a copy.

Smart data entry. Database-backed type-ahead on the receipt form auto-fills owner, vehicle and receipt prefix from history, which cuts entry time substantially for the repeat customers that make up most of the volume. Migrated 2,057 legacy transport records into the new schema with deduplication and validation.

Production hardening. Fixed an XSS vector in the suggestion layer, cut the font bundle from 26MB to 1.5MB, and resolved iOS Safari rendering differences.

Outcome

A digital system that produces a document indistinguishable from the one it replaced, with the history searchable and the receipts verifiable by QR code.

Why it mattered

The pixel-overlay tool is the part I would build again. "Looks the same" is an opinion, and it is the kind of opinion that gets challenged after the first hundred receipts are printed. Rendering the two on top of each other turned an argument into a measurement, and it caught positioning errors that reading the two side by side did not.

The 26MB font bundle is the mirror of that. Embedding Arabic fonts is what makes the RTL rendering reliable, and shipping every weight of three families is what makes the page unusable on a phone. Both facts are true; the work is finding the subset that keeps the first without paying for the second.