(01) — Case study
FlowPress
A QR upload path for a computer shop's printing queue—built, deployed, and then reshaped by what people actually did with it.
FlowPress — project cover
(02) — The problem
Printing in a computer shop is a queue of people handing over flash drives, then waiting while someone opens each file on the one machine wired to the printer.
The shop’s internet is unreliable, so the critical file path could not depend entirely on the cloud.
Walk-in customers on their own phones, and one staff member watching a queue during a rush. Neither installs anything.
(03) — How the architecture changed
The first version put the upload page on the public internet and the backend in my homelab. Connectivity and adoption problems pushed the file path back inside the shop.
This worked and handled more than 100 uploads, but every print depended on the shop connection, the tunnel and a server outside the building.
The new default keeps the critical path on-site. The public route remains available as a fallback instead of becoming another dependency.
(04) — Screens
(05) — What happened when people used it
Building it was the easy half. Changing how people already did the task was the actual problem, and I only partly solved it.
Files passed through the workflow during early use.
They preferred opening the shared folder directly over the admin queue I built.
Some customers kept sending files the way they always had.
Every alternative path had to remain available.
(06) — Where it stands
The upload page, file handoff and print path run at the shop.
The captive-portal upload path and the custom admin queue were tested, but staff chose not to use them.
A shop-local default path, clearer job states and better monitoring.
The workflow still has to coexist with Messenger, USB drives and manual file handling.
Watch staff work for a week before designing the queue.