The Fleet You Could Only Reach in Person

A device in the field needs a different setting. Not a difficult job. What makes it a job is that somebody has to drive there with a laptop, the right cable, and the right version of a configuration tool. Multiply that by a fleet: hundreds of units in other people's premises, run by distributors who are not your employees.

That is the ordinary Tuesday behind software we built for a company in the cashless payment sector. Their hardware takes payments and controls access. They ship it and install it, once. The software is how it keeps working after that, and how it keeps earning.

Installed once, never taken off the wall

A device goes in and it stays in. It is never collected or taken to a bench to be changed. Everything after that happens over the wire: configuration, firmware, the price and item data it sells from, and the logs it keeps.

Those logs are not a support tool, they are the day job. A payment device records sales. An access control device records which card or code opened which door, or started which machine. That is what a customer signs in to read on a Monday, and part of why the portal carries a subscription: base access comes with the hardware, premium holds stored templates, saved projects and advanced encryption.

Somebody still stands at a unit occasionally, and the application does not care how it is reached. Over a USB cable it uses the Web Serial API; over Bluetooth it uses Web Bluetooth, through an adapter that presents exactly what a serial port presents, so the protocol stack and everything above it never learn the difference. Bluetooth is what puts a phone in a technician's hand instead of a laptop and a cable.

One product, three kinds of user

Paying customers manage their own devices. The factory configures devices on the production line before they ship. Support works the same screens, remotely, when a unit misbehaves on a wall somewhere.

Three audiences, one codebase, because the alternative is three tools that eventually disagree about what a device's configuration is, in front of a customer, with money involved. That is what makes the plumbing load bearing.

Multi-tenancy. Distributors see their own devices and nobody else's. Every query carries its tenant, read from the verified token and never from the browser, because a filter the client can influence is not a filter. The devices are locked to their tenant in hardware as well, so the separation holds where the web application is not the thing asking.

User management. Roles come from claims on the token, and screens and individual actions are gated by them. A support engineer and a customer's own technician open the same device and are offered different buttons.

Device management. A registry rather than a list: configuration, firmware, factory setup, remote update windows, key management, cloning one unit's setup onto another, and read-only views for working with no hardware present. Device communication is encrypted, and the build refuses to compile the shortcut that would send it in the clear.

Nothing was hardcoded

A device is configured by setting parameters. Which parameters exist, and which of them a person may touch, depends on three things at once: which of about five device families the unit belongs to, which firmware version it is running, and the access level of whoever is looking. A parameter that is essential on one family is meaningless on another. One that is safe for an engineer is dangerous for a customer's staff. One that did not exist two firmware versions ago cannot be offered to a device that has not been updated.

Conditionals would have covered a demo and failed quietly in the field, and every firmware release would have become a deployment.

So none of it is in the code. The parameters, their ranges and meanings, their family and firmware applicability, and the permission layers all live in secure databases, and the set a person may work with is assembled for that user and that device the moment they connect. Assembling it is a query, not a wait. The screen looks built for that unit because it was.

One codebase then serves the factory, support and the customer with no branch deciding who they are, a new firmware version is a data change rather than a release, and the knowledge of what these devices do stays somewhere it can be corrected and audited.

If you take one idea from this, take that one. The rules of your domain are data. The moment they are code, every change to your business is a deployment.

Where to start

If your product is physical and your customers run more than a few units, the software layer is not an accessory. It is how the thing stays working, how it gets supported, and how it earns after the sale. Deciding that late is what makes it expensive.

We start by tracing how work runs today with the people doing it, not with a demo. You leave with a clearer picture of where work stalls and whether a workflow map or a build is the right next step. We offer a free discovery call to explore whether we can work together to help you scale what is already working.