A branded application can look straightforward in a product presentation: a cabinet list, an allowance and a purchase history. The procurement decision becomes harder when the manufacturer changes an API, an operator leaves, or a completed purchase needs correcting. Someone must own those cases after launch.
Compare build and buy options against the same operating scope. A low initial quote for screens is not comparable to a managed service that includes device integration and support. Equally, a service subscription does not prove that the supplier will handle every exception. The contract and test evidence need to say what is included.
In this guide
Compare three realistic delivery models
An internal team can build and operate the application. A development partner can deliver software that the manufacturer then runs. A software supplier can provide a configured service with an agreed integration and support scope. Hybrid arrangements are also possible, but the responsibilities still need names.
For each proposal, identify who controls the source code, who operates the production service, who maintains the cabinet connection and who supports the employee. Separate commercial ownership from technical access. Owning an app-store account does not necessarily give an operator access to the transaction data needed for settlement.
Avoid scoring the options as universally better or worse. An established engineering team may value direct control; a smaller operator may prefer a service. Both still need evidence that their selected cabinet model and business arrangement can work.
Confirm API rights before estimating development
Request the model, firmware, cloud/API version and third-party access terms. Confirm whether the intended operator can grant access and whether a separately branded app is permitted. A manufacturer dashboard is not proof that all of its functions are available through an external API.
Selfly Cloud describes catalogue and operating information in its own platform. Husky’s Intelligent Fridge page describes its app and API offer. These are useful supplier descriptions, but neither should replace a model-specific API and commercial review.
For MoiPass, Selfly is an existing connection. Husky is assessed by model. No other manufacturer connection follows from this comparison. The API requirements guide provides a questionnaire for that review.
Cost the work that continues after launch
Ask each bidder to separate setup, operation, maintenance and change requests. Name the assumptions behind every estimate: employee population, cabinets, countries, supported platforms, languages and payment route. Do not compare a quotation for one country with one that includes several local benefit arrangements.
Recurring work can include mobile-platform updates, API changes, credential rotation, incident investigation, operator onboarding and corrections to reports. Determine which activities are included and which require a new scope. No percentage or standard price can substitute for this list.
| Responsibility | In-house build | Commissioned software | Configured software service |
|---|---|---|---|
| Product decisions | Name the internal owner | Agree decision rights with the developer | Confirm configuration and change boundaries |
| Cabinet integration | Assign engineering and API access | Include model tests in delivery | Require evidence for the selected model |
| Operations | Budget staffing and tools | Identify the post-handover operator | Define availability and escalation terms |
| Financial exceptions | Design support and records | Include correction cases in acceptance | Demonstrate the agreed correction process |
| Exit | Maintain internal continuity | Secure handover rights and materials | Agree exports, access removal and transition support |
The table identifies questions to price. It does not claim that every service provides every responsibility or that internal development eliminates supplier dependencies.
Treat identity and company boundaries as product requirements
A cabinet app serving several corporate customers needs more than a login screen. Employees, employer administrators, operators and support staff have different reasons to access records. Define their permissions and the process for removing them.
OWASP’s object-level authorisation guidance provides a concrete review point: each requested record needs an appropriate access check. Ask a bidder to show how a user is prevented from reading another employer’s purchase or export, rather than relying on unpredictable identifiers.
Include administrative actions in acceptance testing. An employee leaving one company should not retain new purchase access merely because an old app session remains open. The required timing and behaviour must be agreed for the installation; do not infer them from a generic security statement.
Review hosting, records and the exit together
Decide which organisation determines the purposes of processing, which service providers receive data and how long each record needs to be retained. The European Commission’s information for individuals is a useful starting point for the transparency information employees need.
On-premises hosting can be a delivery option, but it does not automatically remove manufacturer-cloud, payment or device-service dependencies. Ask for an architecture that identifies each remaining connection and its purpose. Agree operational responsibility for backups, updates and incident response rather than treating hosting location as a complete security assessment.
For exit, request an example export, its field definitions and a list of records that will remain with other parties. Confirm how credentials are revoked and how unresolved purchases are handled during transition. A statement that “the data belongs to you” is incomplete without a usable retrieval process.
Buy evidence through a bounded acceptance stage
Require a complete purchase on the exact model, a correction, a lost response and a period export. Use agreed test identities and labelled sample data. Record what was observed, which versions were used and what remains outside the test.
Compare the final proposals using the same acceptance cases and responsibility list. That makes the choice about a service the business can operate, rather than the number of screens in a presentation.
The manufacturer solution describes the MoiPass application and integration scope. If the choice is still open, request a demonstration with your model and responsibility list. We can identify the confirmed connection, the proposed configuration and the work that would require separate validation.