Employee App: Use Cases, Features and Costs

Many German SMEs (the Mittelstand) have two workforces. One sits at a computer, has a company email address and reads the intranet. The other stands on the shop floor, drives delivery routes, cares for residents or works on construction sites. It learns about news from the notice board, the shift supervisor or a private WhatsApp group, where company information ends up on private devices.

An employee app is meant to close this gap. The decision to introduce one is usually made quickly. The three follow-up questions are harder: Which workflows really belong in the app? At what number of users does the calculation tip between an off-the-shelf solution and a custom build? And why does the works council belong in the selection process rather than at the end? This article answers all three.

What is an employee app?

An employee app is a mobile application aimed exclusively at a company's own staff. It bundles internal communication, knowledge and simple workflows on the smartphone. Other names are employee experience app, intranet app or internal communication app.

The decisive difference from other internal systems lies in the target group. The app is built for people who do not work at a desk, often have no company email and use their smartphone during breaks or between two jobs. According to a 2020 report by the investor Emergence Capital, this applies to around 80 percent of workers worldwide, roughly 2.7 billion people (Emergence, The State of Technology for the Deskless Workforce).

This sets it apart from three systems it is often confused with:

• Classic intranet: built for desktop workstations with a company account. Many intranet products now ship with an app, which then serves as the employee app.
• Microsoft Teams or Slack: strong in chat and project work, geared towards knowledge work. For shift-based operations, much is missing without suitable licences and configuration, such as target groups by location.
• HR self-service portals: cover payroll, leave balances and master data, but hardly any communication.

Six use cases where an employee app pays off

Such an app justifies itself through concrete workflows, not through the label "digital communication". These six use cases cover most of what companies want to achieve with it.

Shift schedules and time tracking deliver the greatest operational benefit, and at the same time they involve the most integration effort.

A shift schedule in the app is only as good as the data from the planning system behind it. The typical failure: a shift is swapped in the planning system, the app still shows the old version, and someone turns up at the line at the wrong time. A second, manually maintained copy of the schedule therefore creates more problems than it solves.

The same applies to forms and requests: a leave request, a damage report with a photo or the checklist for a vehicle handover are each small on their own. Taken together, they replace paper, follow-up calls and retyping, provided the data ends up where it is processed further.

News and announcements are the starting point of almost every rollout. The added value compared with the notice board lies in target groups by location, department or language, in push notifications for urgent matters and in a read receipt for content whose acknowledgement must be documented. Feedback and surveys are quick to set up but directly touch on co-determination.

The knowledge use case is easily underestimated. A technician who finds the current manual on their phone at the customer's site saves a call to head office. Onboarding, in turn, pays off above all where staff turnover is high: new employees receive contacts, directions and documents before their first day, and mandatory safety briefings can be mapped with confirmation. Whether this fulfils the respective briefing obligation is checked by the occupational safety specialist.

Features: what is essential and what is optional

Vendors' feature lists are long. For the selection, it helps to separate features without which the app fails in everyday use from features that depend on the use case. Five points are essential:

1. Login without a company email. This is the most common knockout factor. Many employees without a PC workstation have no account in the directory service. An example calculation: if a company has 300 employees, 220 of whom have no company account, an app with a company login only misses almost three quarters of the target group. A second route is therefore needed, such as an activation code or personnel number, and single sign-on via the existing company account for everyone else.
2. Target groups and roles. Content must be controllable by location, department, language and function. Otherwise everyone gets everything, and after three weeks nobody is reading anymore.
3. Push notifications with priorities. A notice about changed shift times is something different from the management newsletter. Anyone who delivers both at the same volume trains the workforce to swipe them away.
4. Multilingual support. In production, logistics and care, a workforce with several native languages is the norm. Automatic translation helps, but for safety briefings it does not replace a checked version.
5. Separate data storage. Company content does not belong in private messengers. The app must keep it cleanly separated, including on private devices.

Chat, shift swaps, time tracking, learning modules, an employee directory and offline mode depend on the use case. Analytics on reach and read rates play a special role. They show whether content gets through. But it is precisely this data that makes an app subject to co-determination; more on this in the section on the works council.

How much does an employee app cost?

The costs depend on a fundamental decision: an off-the-shelf solution as Software-as-a-Service (SaaS) or your own app. The two models add up differently.

Off-the-shelf solution: price per user per month

Off-the-shelf vendors charge per user per month or in user packages. Public prices for orientation (as of October 2026):

• Flip quotes an entry price from €4,950 per year for its "Growth" package for up to 300 employees; larger installations are priced on an individual quote (Flip, Preise). At full capacity, this corresponds to around €1.40 per user per month.
• Connecteam offers its communication module free of charge for up to ten users. Packages start at $29 per month for the first 30 users; each additional user costs $0.50 to $3 per month, depending on the package, with annual billing (Connecteam Pricing).
• Microsoft 365 F1 and F3 are licences for employees without a fixed workstation. Since 1 July 2026, the US list prices have been $3 and $10 per user per month respectively (The Register). If you already use Microsoft 365, check this option first.
• Staffbase and Beekeeper (part of LumApps since 2025) only state prices on request.

On top of the licences come implementation costs: configuration, interfaces to the HR or shift system, training for the editorial team. These items are often missing from the first quote.

Custom build: fixed costs instead of a per-user price

Your own app first costs development and then operation. A cross-platform app in the DACH region starts at around €30,000. Add single sign-on, a second login route and interfaces to two or three existing systems, and an employee app is more likely to start at €50,000. Maintenance, updates and new operating system versions cost 15 to 25 percent of the development costs per year. The detailed breakdown is in the article Having an app developed: costs and process.

Model calculation over three years

The following calculation works with explicitly assumed values. It shows the mechanics.

The assumptions are an off-the-shelf solution at €4 per user per month plus €10,000 for implementation, and a custom build at €60,000 plus 20 percent maintenance (€12,000) and €3,000 hosting per year.

With 300 users, the off-the-shelf solution is clearly cheaper. With 1,500 users, the picture reverses, because licence costs grow with every user while development costs hardly do.

In this calculation, the tipping point is at around 660 users. A company with 400 employees pays €67,600 for the off-the-shelf solution over three years, and therefore significantly less than for its own app. With 1,200 employees, it is €182,800, around 75 percent more than the custom build.

The point is sensitive, however: with a licence price of €1.50 instead of €4, it moves to around 1,760 users. Anyone who builds their own app below this threshold purely because of licence costs is making the project look better than it is.

Employee app comparison: off-the-shelf solution or custom build?

A meaningful employee app comparison does not start with the vendors' feature sets but with four questions. The number of users is only one of them.

The first concerns the workflows. If the app is mainly meant to deliver news, surveys and documents, an off-the-shelf solution covers that. If it intervenes in your own processes, things get tight: an inspection checklist with photos for quality assurance is actually needed as a record in the ERP. With off-the-shelf products, it often ends up as an export or email attachment, or it requires a separate integration.

Closely related is the question of interfaces. With off-the-shelf vendors, every integration is either a ready-made connector or a special project, and with several existing systems, some of them older, a custom build is often the more honest solution.

Then there are data and the roadmap. With SaaS, the vendor decides on features, prices and term. If it raises the per-user price after the minimum term, the tipping point from the model calculation shifts, and switching means a new works agreement and a new rollout. With your own app, both lie with the company, which then also bears responsibility for operation and security.

That leaves the schedule: an off-the-shelf solution can be set up technically within a few weeks. With a works agreement and a pilot phase, the rollout still takes several months. An MVP of your own app usually needs three to six months until pilot operation.

There is a middle way between the two models. Shift planning, an HR system and an ERP have long been in place in most companies. What is missing is the mobile layer that ties them together. A lean custom app can be exactly that: it shows the shift schedule from the planning system, writes job feedback directly to the ERP and forwards leave requests to the HR system, without rebuilding any of these systems.

Technically, cross-platform development with React Native saves the double effort for iOS and Android; the trade-off against Flutter is covered in the framework comparison. Such an app does not need a public store listing; it can be distributed privately to your own organisation (details in the FAQ below).

This results in a three-part recommendation. An off-the-shelf solution if communication is the focus and the number of users is below the tipping point. A lean custom app as a connecting layer if the most important use cases depend on existing systems. A comprehensive custom build if individual workflows form the core and the number of users is high. The systematic trade-off is described in the article SaaS vs. customised software.

Data protection and the works council: what needs to be clarified before launch

In short: almost every employee app needs a works agreement, and data protection is also regulated in it. The details depend on two sets of rules.

Works council: co-determination under § 87 BetrVG

Under § 87 (1) no. 6 BetrVG (Betriebsverfassungsgesetz, the German Works Constitution Act), the works council has a right of co-determination when technical equipment is introduced that is designed to monitor the behaviour or performance of employees. According to the established case law of the Federal Labour Court (BAG), it is sufficient that the equipment is objectively suitable for monitoring. Whether the company actually evaluates the data is irrelevant.

How low this threshold is was shown by a 2016 decision: the Federal Labour Court even affirmed co-determination for an employer's Facebook page, because visitors could publish posts there about the behaviour or performance of individual employees (BAG, 13.12.2016, 1 ABR 7/15, report by LTO). An app with read receipts, time tracking or usage statistics lies well above it.

In practice, this means: the works council negotiates the works agreement in parallel with the vendor selection. Purpose, features, permissible analytics, access rights and deletion periods are defined jointly. If you only involve the works council after signing the contract, you negotiate under time pressure about a product that has already been bought.

GDPR and private smartphones

The short version: the legal basis previously used in the BDSG (Bundesdatenschutzgesetz, the German Federal Data Protection Act) no longer holds; the GDPR itself or a works agreement are viable. The background is a ruling of 30 March 2023: the Court of Justice of the European Union (CJEU) held that a general clause such as the one in Hesse (§ 23 (1) HDSIG, the Hessian data protection act) is unlikely to meet the requirements of Art. 88 GDPR (C-34/21).

The identically worded rule in § 26 (1) sentence 1 BDSG has since been widely regarded as contrary to EU law.

Companies therefore base the processing directly on the GDPR, for example on necessity for the employment relationship, or on a works agreement under Art. 88 GDPR. Since a further CJEU ruling of 19 December 2024 (C-65/23), it has been settled that such a works agreement must also comply with the general principles of the GDPR.

With an external vendor, a data processing agreement under Art. 28 GDPR and a check of the storage location are added.

Private smartphones, known in the jargon as Bring Your Own Device (BYOD), are the most delicate point. Whether employees must install a work app on their private device is disputed under employment law.

The safe approach is voluntary use with an equivalent alternative, such as a terminal in the break room or a company device. And if you expect work messages to be read outside working hours, you must also regulate the working time question. For the specific design of both points, employment law advice is advisable.

Introduction in five steps

Whether the app is used is decided less by the technology than by the rollout. A sequence that catches the typical pitfalls:

1. Define the goal and target group. Which two or three use cases should work in the first six months, and for whom?
2. Involve the works council and data protection. Define the feature set and analytics jointly, and negotiate the works agreement in parallel with the selection.
3. Pilot at one location. Four to eight weeks with real content, then adjust.
4. Build an editorial team. This step determines success after launch. An app without regular, relevant content becomes a dead icon on the home screen. You need one responsible person per location, an editorial plan and a fixed rule on which information is only distributed via the app, such as the shift schedule.
5. Rollout and measurement. Activation rate, reach of mandatory content and feedback from the workforce, in the form agreed with the works council.

Frequently asked questions about employee apps

What is the difference between an employee app and an intranet?

An intranet is built for desktop workstations with a company account, an employee app for employees who work on the move or without a PC. Many intranet vendors now ship with an app that covers both groups.

Does an employee app have to be in the App Store?

No. Apple allows private distribution as a custom app to specific organisations via Apple Business, rolled out via Mobile Device Management (MDM) or redemption code. Apple still reviews the app (Apple Developer, Custom Apps). Google offers private apps via Managed Google Play, which are only visible to the specified organisation (Google Play Help).

How much does an employee app cost per user?

Off-the-shelf solutions cost a few euros per user per month, plus implementation. A custom build costs development and maintenance, starting from a mid five-figure sum.

Can an employee app also run as a web app?

Yes. A progressive web app does not need a store and, since iOS 16.4, can also receive push notifications on the iPhone once it has been added to the home screen. For camera, offline or device features, a native or cross-platform app is the more robust choice.

Conclusion

An employee app makes sense if a relevant part of the workforce works without a PC and is currently informed via notices, word of mouth or private messengers. For communication and simple forms, an off-the-shelf solution is sufficient in most cases. A custom build pays off with large numbers of users, individual workflows or many interfaces. In both cases, the works council is at the table from the start.

The next step is a calculation, not a vendor demo: enter your number of users and the licence price from the first quote into the model calculation.

If the result is close to the tipping point, or if your most important use case depends on two or three existing systems, a closer comparison is worthwhile before you sign a three-year contract. At Next Levels, we support you with this assessment and, if it becomes your own app, with app development through to rollout.