Rotterdam buys mobile apps that have to work away from a desk
The demand here is shaped by what the city does: port and terminal operations, freight forwarding and customs handling, shipping services, construction, energy, wholesale and the industrial businesses around them. The products they commission are worn on the body of a working day. A driver confirming a collection, a foreman signing off an inspection, a technician logging a repair, a planner reassigning a slot, a warehouse operator scanning a pallet at the back of a cold store where the signal dies.
That user is not browsing. They have gloves on, they are standing up, they have a few seconds, and the alternative to your product is a clipboard that never crashes. It is a genuinely different design problem from a consumer mobile app, and a studio whose experience is all lifestyle apps will underestimate it in ways that only appear after go live.
Offline behaviour is the expensive part, and it is not optional
Coverage in industrial environments is unreliable in a specific, awkward way: not absent but intermittent, which is harder to handle than no connection at all. A product built for constant connectivity will hang on requests that never complete and lose work the user believes was saved. A product built properly caches what is needed before the shift, records actions locally, queues them, reconciles when the signal returns and resolves the conflicts that arise when two people changed the same record in the meantime.
That conflict resolution is where estimates break. Ask every bidder how their design decides who wins when two offline edits collide, and what the user sees when that happens. Ask whether the price includes testing on a genuinely poor connection rather than on office wifi. Offline capability can double the engineering effort on a mobile app, and it is the single most common cause of an operational product being rejected by the people expected to use it.
Battery, background work and what the operating system permits
Field mobile apps want to track location, sync in the background and stay responsive for a full shift. The operating systems on both platforms are actively hostile to all three, because they protect battery life aggressively and suspend applications that are not in front of the user. Background location in particular requires explicit permission, a clear justification at review time and a design that survives the user denying it.
Ask candidates how they handle a device that suspends the product mid sync, what happens when the phone restarts during a shift, and how they keep power consumption acceptable across ten hours. Ask what the fallback is when a user declines a permission, since in a workforce context that conversation also involves your works council and your employment lawyer, not just your developer.
Rugged devices, scanners and the hardware question
Operational mobile apps rarely run on the phone in someone's pocket. There are rugged handhelds, vehicle mounted terminals, dedicated scanners, label printers and sometimes older devices running an operating system version several releases behind current. Each of these narrows the technology choices and widens the testing effort, and none of them is visible in a requirement written from an office.
Name the exact hardware in the brief, including the oldest device that must be supported, and provide physical units to the supplier early. Ask how scanning is handled, because hardware scanner integration and camera based scanning behave differently and perform differently in poor light. If the fleet is managed centrally, say so: distribution through a device management platform rather than a public store changes the release process, and a team that has never done it will find out on your schedule.
Integrating with the systems that already run the operation
The mobile app is almost always the visible edge of an estate that already exists: a transport or warehouse management system, an enterprise resource planning platform, a customs or terminal system, a telematics provider, occasionally a partner interface that only accepts files at fixed intervals. The phone work is rarely the hard part. Getting reliable, timely data in and out of those systems is.
List every one in the brief and name who controls each, including the vendor contact and whether a test environment exists. A missing test environment is worth weeks. Ask suppliers which of these systems they have integrated before and what the experience was like, and treat a candid complaint as a good sign. Ask also what the product does when an upstream system is unavailable, because in an operational setting a frozen screen stops work in the physical world.
Rolling out to a workforce is a project of its own
A mobile app for employees can be technically finished and still fail, because adoption is not automatic when the old process still works. Budget for enrolment, for short training in the language people actually use on the floor, for a support route on day one that is not an email address, and for a period where both the old and new processes run together.
Ask the supplier what they include for rollout and what they expect from you. Ask how the product handles a shared device used by several people across a day, how sessions end, and what a supervisor sees when something was not recorded. These questions rarely appear in a brief written for a consumer product and they decide whether an operational deployment sticks.
Comparing Rotterdam suppliers on operational evidence
Ask each candidate for a live mobile app used by a workforce rather than by consumers, and ask what broke in the first month. Ask how they measure whether it is being used, how a crash on a warehouse handheld reaches them, and what response commitment applies during a night shift. Ask what they would refuse to build in the available time.
Then brief three suppliers with an identical written document and compare their assumptions about offline behaviour, devices and integrations rather than their totals. If the same programme also needs backend or platform engineering, look separately at software firms working locally instead of asking one team to cover everything. To survey the wider field first, start from the directory of mobile app developers, and when the brief is ready, request comparable proposals from verified suppliers.