Benefits app for submitting supporting documents

For a client delivering a project for a public-sector organisation, we developed a benefits app for submitting supporting documents using a smartphone camera. The focus was on a cross-platform implementation, the secure transfer of image data via interfaces, and the accompanying release management for publication in the app stores. The project ran over an extended period and, in addition to app development, included organisational and technical tasks related to operating the releases.

Initial situation

A client was delivering the project for a public-sector organisation and was looking for support with implementing a mobile application. The task was to provide an app that would allow benefits-related supporting documents to be captured and submitted using a smartphone camera. This required a cross-platform technical foundation, suitable interfaces for transferring the image data, and a reliable publication process for the mobile stores.

Solution

We developed a cross-platform app development solution based on Angular and Ionic. In addition, we handled release management and app store deployments using a CI/CD process; CI/CD refers to an end-to-end process that structures the build, testing and deployment of an application. We also implemented interfaces for the GDPR-compliant transfer of image data.

The project ran from April 2019 to July 2021. The team consisted of 4 people.

Result

What was delivered was a mobile, cross-platform benefits app for submitting benefits-related supporting documents using a smartphone camera. The project also included interfaces for the GDPR-compliant transfer of image data, as well as release management with app store deployments.

The duration was 28 months. The project was completed.

Technology

• Angular for implementing the application
• Ionic for the cross-platform app
• Node.js as part of the project’s technical foundation
• Web Components for reusable interface elements
• TypeScript as the application’s programming language
• Nx for organising the development workspace and project structure
• Capacitor for connecting the web application to mobile device functions
• Azure DevOps for release management and CI/CD
• MS SQL Server for data storage
• OAuth2 and OIDC for authentication and authorisation; authentication verifies identities, authorisation controls access rights

Why a benefits app is a good fit for this task

If supporting documents need to be captured on the move and passed on to a specialist application, a benefits app is often an obvious solution. The smartphone camera is immediately available, the usage context is clear, and submission can take place where the document actually exists. For organisations, what matters here is that the application should not only be easy to use on the device, but should also integrate cleanly into existing processes.

In projects like these, there is a strong case for a cross-platform implementation. It creates a shared functional basis for different mobile operating systems. This reduces coordination effort between separate development tracks and simplifies maintenance, provided the requirements for device integration and usability are a good fit. A cross-platform app is an application whose core is developed jointly for several systems.

The interfaces are just as crucial. They connect the mobile application to the downstream systems, pass on images and metadata, and ensure that the process does not fail because of media breaks. An interface is a clearly defined technical connection between applications. In image-based submission processes in particular, formats, file sizes, transfer routes and feedback all need to work together sensibly. Otherwise, what appears to be a simple mobile function can quickly turn into an error-prone overall process.

For public-sector and business-critical environments, there is another important point: handling sensitive data requires a technically robust and traceable design. This affects areas such as login, permissions, transmission routes and logging. Whether a specific solution is legally sufficient should be reviewed by the client with their legal department or data protection officer.

The publication process is also often underestimated. A mobile application does not end with the completed functionality. Approvals, packaging, store reviews and managed updates are all typical parts of the process. That is why it makes sense to plan development and publication together. Anyone preparing a solution like this should look not only at the app itself, but at the interaction between web development, mobile use, interfaces and deployment as a single overall task.

How a project for a benefits app is typically delivered

In projects of this kind, it makes sense to begin by clarifying the functional process. This is not just about image capture and transmission, but also about questions such as login, feedback to users, error scenarios and integration into existing processing workflows. With mobile applications in particular, it is worth considering usage situations early on: fluctuating network quality, different devices and the expectation that key steps should be understandable without lengthy familiarisation.

The next step is to define the solution conceptually. Typically, the mobile interface, the interfaces and the operational aspects are described separately but planned together. This helps to make risks visible at an early stage. For example, if the app captures images, it must be defined in which format they are passed on, which checks take place and what responses from the target systems will look like. It is equally important to decide which parts belong in the app and which should sit in the backend or middleware. Middleware is an intermediary software layer between applications.

Implementation then follows, with regular coordination. For decision-makers, what matters here is less the internal development cadence than whether functional decisions can be made promptly. Mobile projects often stall when interfaces, interfaces and approval processes are planned independently of one another. A better approach is one in which these areas are continuously aligned.

Alongside the actual development, there is quality assurance and publication. With apps in particular, real devices, typical capture situations and problematic edge cases need to be tested. Release management defines how new versions are prepared, approved and distributed. This creates traceability and reduces the risk of disorderly releases.

After go-live, work on projects like these is not usually finished. Operations, bug fixing, store-related adjustments and changes to connected systems remain an ongoing part of the work. Anyone planning a similar project can start by structuring the scope with the project check, or use a no-obligation initial consultation to sort through the starting point. This usually produces a more reliable picture more quickly of which building blocks are actually needed.

Typical pitfalls in mobile document submission processes

At first glance, a mobile solution for supporting documents often seems manageable. In practice, however, the risks usually lie not in the individual capture function, but in the overall process. A typical example is that images can vary greatly on real devices: poor lighting conditions, documents photographed at an angle or very large files. If the application is not prepared for this, usability and data quality both suffer.

Another pitfall is unclear interface responsibilities. There are often several parties involved: the mobile application, an intermediary service and a target system. If it is not clearly defined who accepts, checks, stores or returns which data, error patterns arise that are difficult to assign from a business perspective. For clients, it is therefore important to document data flows and responsibilities in writing at an early stage.

Security and data protection must also be part of the architecture from the outset. This includes managed login, secured transmission routes, traceable permissions and a deliberate approach to temporary data on the device. Architecture describes the fundamental structure of a software system and how its parts interact. The legal and organisational requirements that apply in each case should be agreed by organisations with their legal department or data protection officer.

Further typical challenges become apparent during operation. App stores have their own review processes and requirements, mobile operating systems change, and connected systems continue to evolve as well. Without a managed publication process, even a minor change quickly becomes time-consuming. That is why operations, monitoring and update capability should not only be considered towards the end. Monitoring means continuously observing the technical condition of a system.

Finally, the lifespan of the solution plays a major role. A document submission app is rarely used in isolation; it is usually part of a longer functional chain. That is why a structure that allows for extensions is worthwhile, rather than one that only maps the initial functional version. For projects like these, we recommend planning not only the interface but also the data model, interfaces and operation in the Microsoft Cloud, or the target environment, as one connected task. This makes later changes easier to assess and implement in a more orderly way.