Scanner app: one product, N configurations
25 juillet 2026
The trap of the "simple" scanner
A scanning application looks trivial: read a barcode, show a product. Then the real cases arrive.
One store scans standard EAN-13 codes. Another uses prefixed internal codes. A third weighs its items and works with barcodes carrying a variable weight. A fourth wants to reject any code missing from its catalogue; a fifth wants the record created on the fly instead.
The usual answer is to duplicate the application per client. By the third version, every fix has to be applied three times, and one of the three will be forgotten.
The choice: configure, don't fork
For Inopos we took the problem the other way round: a single application, whose behaviour is described by a configuration.
What can be set without touching the code:
- Accepted scan types: EAN-13, EAN-8, Code 128, QR, or a subset per outlet.
- Validation rules: unknown code accepted, rejected, or held for review.
- Prefix handling: recognise an internal code, extract the useful part, ignore the rest.
- The post-scan flow: quantity, price, visual check, or immediate confirmation.
The result: deploying to a new client means writing a configuration, not opening a branch.
What that changes in production
One binary to maintain. A bug fix immediately benefits every outlet. No version matrix to track.
Tests become useful. Because variants are data rather than code, you can test rule combinations without multiplying integration scenarios.
Client rollout takes minutes. Installation no longer needs a developer: the settings are editable by the team that knows the store.
The technical decisions that matter
Treat the configuration as a contract. It's validated on load against an explicit schema. An incorrect configuration fails immediately with a clear message, not three screens later, in the middle of a stock count.
Plan for offline from the start. A store has dead zones. Scans are stored locally then synced; the user shouldn't have to understand any of that.
Don't make configurable what doesn't vary. Every option added is one more combination to test. We only open a setting once a second client genuinely needs it.
Optimise the gesture, not the screen. On the shop floor the user scans one-handed. The number of taps after a scan matters more than the look of the interface.
Is it worth it for you?
This model makes sense if you expect to deploy the same application across several slightly different contexts: several brands, several sites, several trades.
Conversely, for a single stable use case, configuration adds complexity with no payoff. A fixed application is then simpler to write and maintain.
You can see the result on the scanner app page. Have a similar project? Write to us.