Much of the mobile app work bought in Munich never reaches a public store
The buyers here are disproportionately industrial: vehicle and component manufacturers, machinery and automation, insurance and finance, medical technology, and the research heavy firms that cluster around them. What they commission is often an internal tool rather than a consumer product. A technician's companion on the shop floor, a service engineer's job sheet, a sales configurator, a quality inspection record, a tool that pairs with a machine over a short range radio link.
That changes almost every assumption a consumer focused mobile app studio brings. Success is not installs, it is whether a shift can be completed faster. The audience is a known, finite group of employees. The competition is a paper form that already works. And the distribution channel is your own device management platform rather than a storefront, which removes some problems and introduces others that buyers rarely price.
Internal distribution changes the whole delivery plan
Publishing to managed devices through an enterprise mobility platform means no public review queue, faster releases and full control over who gets which version. It also means your supplier has to work with your device management team, respect the security policies applied to those devices, and handle enrolment, certificate renewal and version rollout across a fleet that is not always online.
Ask candidates directly whether they have shipped a mobile app through a managed device platform rather than a store, and which one. Ask how they handle a device that has been offline for weeks, how a version is rolled back, and what happens when the security policy blocks something the product needs. A team that has only published to stores will discover these constraints on your schedule, and each discovery costs a sprint.
Apps that talk to machines, vehicles and field systems
A large share of local requirements involve hardware: a short range radio connection to a device, a scanner, a diagnostic interface, a sensor, a printer in a workshop. Hardware integration is the part of a mobile app project that most reliably exceeds its estimate, because the documentation is incomplete, the firmware behaves differently across revisions, and the failure modes only appear in the real environment.
Insist on early access to actual hardware for the supplier, and insist that the estimate includes time on site. Ask what happens when the connection drops halfway through a transaction, how the product behaves with no network at all in a basement or a hall, and how firmware variation is handled. Then ask for a reference where hardware integration went badly, because the useful signal is how a team behaved when the device did not cooperate.
Internal reviews gate the release, and they take real time
An internal mobile app touching employee data will pass through data protection review and, in most established companies here, a works council consultation. That is not an obstacle to route around. It is a stakeholder with legitimate authority and a calendar of its own. Anything that could be read as performance monitoring, location tracking of staff, or collection of data beyond the task will attract questions and can stop a rollout that is otherwise finished.
Design for it instead. Collect the minimum, document why each permission exists, keep employee data out of logs and crash reports, and be able to explain retention in one page. Ask suppliers whether they have been through this process before and what the review asked for. Build the consultation into the plan at the start, because adding it at the end turns a completed build into a shelved one.
Procurement habits, documentation and change control
Corporate buyers here expect a mobile app specification with acceptance criteria, a documented test approach, and change control that is written rather than conversational. Suppliers used to this market price that overhead in and deliver it. Suppliers who are not will quote lower and then struggle with the paperwork, which is where the relationship sours.
Decide which you want. If the requirement is genuinely fixed, a defined scope with acceptance criteria is efficient and the documentation is not waste. If the product is exploratory, an iterative arrangement with a named product owner on your side works better, but it needs someone empowered to decide weekly. Ask what documentation is included as a deliverable: architecture notes, interface descriptions, operating instructions and a handover package should be named items with a price, not a favour at the end.
Security review, standards and the questions that arrive late
Expect a mobile app security assessment covering credential storage on the device, certificate handling, what is written to logs, session expiry, behaviour on a compromised device and how third party libraries are tracked. Certification against a recognised standard such as ISO 27001 is frequently requested from suppliers, and a smaller studio may have the substance without the certificate.
Find that out in week one rather than in week ten. Send the diligence questions with the brief. Ask whether the price includes fixing what an external test finds, or whether remediation is billed separately, because a findings report arriving shortly before a planned rollout is a schedule event rather than a document.
Shortlisting Munich suppliers on operations rather than on decks
Ask each candidate for a live mobile app, ideally one in a comparable setting, and for its release history. Ask who submits releases, how a rollback works, how a crash affecting many users is detected, and what the response commitment is outside working hours if the product supports a shift that runs at night. Ask what they would refuse to build in your timeframe.
Then brief three suppliers with an identical written document and compare assumptions rather than totals. If the same programme also needs platform engineering, look separately at software firms working in the city rather than 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 and judge them against the requirement.