Candy Van
The app a family candy wholesaler uses on its delivery vans: one person takes the order inside the store, the other loads it in the van as it is being built, and the store gets a printed receipt before the van leaves.
Today, without it:
- van waits for the full order
- then starts loading
- receipt still needed
With Candy Van:
- Store: Takes the order (On a phone in the store)
- One live order (Both phones, always the same)
- Van: Picks and loads (On a phone in the van)
- End of order (Tells the van it is done)
- Receipt printed (From either phone)
- Order history (Kept even without signal)
- Order ready (Clears both phones)
The hard part: Loading starts with the first item, not the last.
The problem
Each delivery van is worked by two people: one takes the order inside the store, the other picks and loads it in the van. If the van has to wait for the finished order, the person outside stands idle while the list is built, and every stop takes longer than it should. The order needs to reach the van while it is still being taken, so loading starts with the first item, not the last.
What it does
- The order appears in the van while it is still being taken in the store
- A pick list that shows what is still left to load
- Receipts printed on the spot, with Bluetooth and PDF as backups
- An order history that survives a bad signal
- Several vans, each with its own code, products, and customers
Faster stops, lighter days
In daily use on the route, the difference shows at every stop. Loading begins with the first item instead of the last, so the van is ready moments after the order is taken rather than long after it. The minutes saved at each stop add up across a full day of deliveries. The work is lighter too: the van no longer waits and then rushes to catch up, and no one has to carry the order in their head. Less waiting, less rushing, and a calmer route from the first stop to the last.
Two phones, one order
The order lives in Supabase, and both phones follow it through Supabase Realtime, re-reading it whenever the connection returns or the screen wakes. An edit lock stops two people changing it at once, the van sees items in the order they were chosen, and an End of order / Order ready exchange clears it on both phones together.
Software that meets the physical world
Receipts print on a Star SM-T300i thermal printer through Star’s PassPRNT app, from iPhone and Android. Each of these problems only showed up in the field:
- Receipts sent as compact HTML inside a link, trimmed byte by byte because iOS silently cuts long links short
- Long receipts split into separate print jobs, because the printer app rejects anything over one metre
- Printing pinned to Bluetooth, so a blank printer setting can no longer cause a connection error
- Pages drawn at 576 pixels to match the printer’s 576 dots, with lines narrowed for Android’s wider bold type
- The live order re-read the moment PassPRNT hands control back to the app
Records that survive a bad signal
Every printed order is queued on the phone and uploaded to an order history when the connection allows, with each upload recorded once, however many times it is retried. Database views summarise what each customer buys and on which day.
Built for more than one van
- Each van has its own code, products, customers, live order, and receipt header
- Row-level security keeps vans apart, so a phone signed in to one van cannot read another’s data
- Van codes are stored only as hashes, with a lockout after repeated wrong attempts
The diagram on this page is an illustrative system flow, not a screenshot of the product.