A SOFTWARE PLATFORM CONCEPT FOR PETER BALFOUR & TEAM01 / HARDWARE
The machine
The screen and physical devices: printer, scale, scanner, payment terminal and anything else the use case needs.
The software platform
Plug in once.
Scale to thousands.
The machine, its hardware controls and the customer-facing app each have a separate job. That makes a new machine simple to set up, while letting us change one layer without rebuilding everything else.
A startup app installed during manufacture would guide the first connection and load the right operator experience.
See how the layers fit togetherOne machine, four clear parts
Customer front endWhat the customer sees and uses
Hardware middlewareOne interface for printers, scales, scanners and payments
Machine hardwareThe physical screen and connected devices
Factory-installed startup appGets the machine online and ready for its operator
Centrally configured, updated and monitored across the fleet.
The architecture
Four parts. Each can change independently.
Keeping these jobs separate makes the platform easier to adapt for different manufacturers, operators and industries.
02 / MIDDLEWARE
The hardware translator
A separate software layer talks to those devices and gives the front end consistent functions, such as “print label” or “read weight”.
03 / FRONT END
The operator’s experience
The branded screens and customer journey can be tailored for each operator without changing the hardware layer underneath.
04 / BOOTSTRAP
The startup app
Installed at manufacture, it starts when the machine turns on, helps it connect and loads the right operator configuration and software.
Why the separation matters: changing a printer should mean updating its middleware connection, not rewriting the customer app.
A practical example
What if the printer changes?
The customer still taps “Print label” in the same front end. We update the middleware so that instruction works with the new printer model.
The customer journey stays the same. The printer integration changes in one place.
Plug and play rollout
For the operator: plug in, connect, follow the screen.
The factory-installed startup app would handle first setup. The operator should not need to install a different app on every machine.
01 / PLUG IN
Power up
The machine arrives with the startup app already installed during manufacture.
02 / CONNECT
Get online
The operator connects the machine to the internet. The startup app contacts the platform.
03 / FOLLOW THE SCREEN
Activate
On-screen instructions link the machine to the operator and load the right brand, services and settings.
From one central place, the team could manage configuration, software updates and machine monitoring as the fleet grows.
imageHOLDERS Mission Control
Concept screen · sample data
All operators
One view of configuration, updates and real-world machine faults across the network.
Example fleet overview
Machines28,400
Online28,166
Need attention234
Example operators4
Operator fleets
| Operator | Machines | Online | Attention |
|---|---|---|---|
| Royal Mail | 12,400 | 12,278 | 122 |
| McDonald's | 8,200 | 8,150 | 50 |
| Five Guys | 1,800 | 1,788 | 12 |
| Romania Post | 6,000 | 5,950 | 50 |
Issues needing action
Royal Mail · label paper empty18 machines · refill required
McDonald's · no network connection50 machines offline · check connectivity
Five Guys · receipt paper empty12 machines · refill required
Romania Post · printer fault7 machines · on-site check required
Illustrative names and figures only. These organisations are examples, not stated Shiptronic clients or partners.
Two ways to use it
We build the screens, or the operator does.
Either way, the front end uses the same underlying platform and hardware middleware.
We build the front end
We design and maintain a branded customer journey for the operator, using the common platform underneath.
Use our SDK and APIs
We provide a software development kit and documented endpoints so the operator’s team can build its own screens quickly without starting the device integrations from scratch.
Beyond shipping
A platform for self-service, not just parcels.
Postal kiosks are one use case. The same approach could support other industries by changing the customer journey, integrations and operator settings.
Shipping, collections and returns.
Returns, collection and service desks.
Self-service check-in and ticket journeys.
Forms, payments and guided transactions.
Illustrative commercial model
Value after the machine is installed.
A per-machine licence for the ongoing software, a one-off fee for operator-specific work, and clear charges only when cloud usage exceeds an agreed allowance.
Charge per active machine, per month. Includes the platform, normal updates, standard cloud use and fleet monitoring.
Operator builds its front end with our SDK£15–£25 / machine / month
We build and maintain the front end£30–£50 / machine / month
Quote a separate lump sum after scoping operator branding, workflows, hardware connections, APIs, testing and launch. Agree payment milestones in the contract.
Include ordinary storage and monitoring in the licence. Agree allowances, then bill measurable excess storage, logs or traffic, or a higher support level, against a clear rate card.
Planning example: 10,000 active machines × £35 per month = £350,000 per month
That is £4.2 million a year at full rollout, before a one-off setup fee or any cloud overages. It assumes all 10,000 machines are active and paying for 12 months.
Illustrative planning ranges, not a quote or revenue forecast. Final pricing depends on the operator's value, included features, service levels, rollout schedule and volume discounts. A pilot should measure cloud use and support demand before setting allowances or overage rates.
See a use case