The City App Is Becoming the New Front Door to Government
Cities are beginning to present a single app as the answer to fragmented public services. Residents would use one account to register a new address, apply for housing support, book an appointment, receive an official decision or submit a missing document. Notifications would replace letters, stored identity data would reduce repetitive form filling, and the status of an application would be visible without calling the responsible office.
The model is attractive because it gives municipal digitalisation a clear public face. It is also easy to misunderstand. A city app can bring several services into one interface, but it cannot make an inefficient administrative process efficient on its own. When departments continue to use incompatible systems, request information the municipality already holds and move applications manually between offices, the app becomes a polished entrance to an unchanged bureaucracy.
The decisive work therefore takes place behind the screen. Before a city commissions another interface, it needs shared identity infrastructure, interoperable registers, clear responsibility for data, common service standards and processes designed to run digitally from beginning to end. Without those foundations, the app may improve navigation while leaving processing times, administrative costs and employee workloads largely untouched.
One account is useful only when it opens the whole system
A resident does not experience municipal administration as a collection of departments. A move may involve the residents’ registration office, vehicle registration, parking permits, schools, waste services and local taxes. The administration, however, often handles each of these matters separately.
A city app promises to remove that fragmentation by providing one account through which residents can access multiple services. Germany’s development of central infrastructure such as BundID points in this direction. A shared digital identity can authenticate users, prefill selected personal information, receive official correspondence and show the status of online applications.
This is more consequential than a municipal app with a list of links. A genuine digital front door must recognise the resident consistently across services and allow information to move securely between the front end and the responsible authority.
When each municipal department still demands a separate account or authentication method, the city has not created one digital service. It has collected several portals behind one icon. Residents continue to encounter different logins, terminology and document requirements once they move beyond the opening screen.
Cities should therefore avoid building a new proprietary identity system when a trusted national or European component can perform that function. The local interface may reflect municipal services and language, but authentication should be reusable across administrative levels. A resident should not need one identity for the city, another for the region and a third for national government.
A digital form does not constitute a digital process
Many public services are described as digital because an application can be submitted online. What happens afterwards often remains largely analogue.
An employee downloads the form, checks it manually and enters the same information into a specialist system. Documents arrive as attachments that cannot be processed automatically. Another department requests data already held elsewhere in the municipality. The final decision is printed because the internal workflow cannot return it through the digital channel.
From the resident’s perspective, the service began online. From the administration’s perspective, it became a conventional paper process as soon as the form arrived. A city app cannot correct this discontinuity. It may even conceal it by creating the impression of an integrated service while staff continue performing duplicate work behind the interface.
The process should be redesigned before it is placed in the app. Each required data point needs a reason. Information already available in an authoritative register should not be requested again unless the law requires confirmation. Routine checks should be automated where appropriate, while cases requiring judgement should be directed to an employee with the relevant information already assembled.
Digitisation should also remove unnecessary procedural steps rather than reproducing them. A form created decades ago around paper signatures, physical files and communication by post should not automatically become the template for the online version. The service must be reconsidered around what the authority actually needs to reach a lawful decision.
The app should follow a life event, not the organisational chart
Municipal websites and digital portals are commonly organised according to administrative structures. Residents are expected to know which office handles a particular issue, even when the boundaries between departments are not obvious.
A more useful city app organises services around events: moving home, starting a business, having a child, renovating a property, arranging care for a relative or dealing with a death. Each event can involve several authorities and applications, but the resident should not be required to coordinate them independently.
Consider a person moving into a city. Once the new address has been verified, the app could identify relevant services and guide the resident through them in a logical order. It might offer vehicle registration, a residential parking permit, school information, waste collection details and local notifications. With permission, the verified address could be reused rather than entered repeatedly.
This does not mean that every department must use the same specialist software. It means that their systems must exchange defined information and report progress through a common service layer.
The difference is important. Replacing every municipal system at once would be expensive and operationally risky. Building standard interfaces between them can deliver a coherent resident experience while allowing specialist systems to remain where they still perform adequately.
Municipalities need shared standards more than unique apps
A city may be tempted to commission a distinctive platform that reflects its brand and local priorities. That approach can lead to duplication when neighbouring municipalities build separate versions of the same administrative functions.
The underlying needs are rarely unique. Identity verification, secure messages, payments, appointment booking, document submission and application tracking are common across local government. The same applies to services such as address registration, business licensing and housing applications, even when local rules create some variation.
Shared components allow municipalities to spread development and security costs, reuse tested services and avoid dependence on a small number of local specialists. They also make it easier for residents who move between cities or interact with several levels of government.
Local differentiation still has a place. Cities may provide neighbourhood information, mobility services, event notifications or participatory tools that are genuinely specific to the area. The basic administrative infrastructure should not need to be reinvented each time.
Procurement should reflect that distinction. Rather than buying a closed municipal application, cities can commission modular services based on open standards. The app then becomes one channel through which residents access a wider public digital infrastructure, not an isolated system that must reproduce every function itself.
The interface cannot own the resident
A city app brings together highly sensitive information. It may know a resident’s address, family status, applications, payments, permits and communication with public authorities. The company supplying the interface could gain considerable operational influence even when the municipality formally remains the data controller.
This makes architectural control as important as visual design. Cities need to know where information is stored, which subcontractors can access it, how data moves between systems and whether the municipality can change supplier without losing functionality or historical records. Contracts should require exportable data, documented interfaces and a practical exit process.
A platform that works well but can be operated only by one vendor creates long-term dependency. The city may face rising costs, slower development or difficulty integrating new services. Replacing the supplier becomes politically and technically difficult because the app has become the principal relationship between the municipality and its residents.
The platform should therefore be built around public control of identity, data definitions and service interfaces. Private providers can contribute technology and expertise, but the municipality must retain the ability to govern the system and commission individual components competitively.
Consent also requires careful design. Residents should understand which information is needed for a specific service and when it may be reused. Accepting the app’s general terms should not become permission for unrestricted exchange of personal data across departments.
A city app must support people who do not use it
Digital services can reduce administrative effort only when a substantial share of residents can use them successfully. An app designed around the most technically confident users may shift work rather than remove it.
Residents may lack a compatible smartphone, digital identification, language proficiency or confidence in electronic procedures. People with disabilities can encounter interfaces that technically comply with accessibility standards but remain difficult to navigate. Others may begin an application online and need human assistance before completing it.
The city should not preserve a separate manual bureaucracy for every channel. It should allow employees in service centres or call centres to work through the same underlying process on behalf of the resident. A staff member might help complete a digital application, verify documents and submit it through the same system used by the app.
This channel-independent model is more efficient than maintaining separate online, postal and counter processes. The resident chooses how to interact, while the administration processes the case through a common workflow.
A city app should therefore be assessed not only by download numbers but by successful completion rates. High abandonment, repeated support calls and applications that must be corrected manually reveal weaknesses that user registrations alone cannot show.
Notifications are valuable only when residents can act on them
A central digital postbox can eliminate delays and uncertainty associated with paper correspondence. Residents can receive official decisions, requests for additional documents and reminders within the same account used to submit the application.
The greater improvement comes from making the communication actionable. A message stating that evidence is missing should link directly to the relevant case and allow the document to be uploaded. A fee request should offer an integrated payment route. An appointment invitation should show available times without requiring a separate telephone call. A decision should explain the next step and any applicable deadline.
One-way digitisation merely replaces a letter with a PDF. Two-way communication changes the process because the resident and the authority can resolve questions within the case itself.
Application tracking is similarly useful only when status labels have meaning. “In progress” tells the resident little if it remains unchanged for several months. A better system shows whether the application has been received, whether documents are missing, which stage is complete and when further action is expected.
Transparency can reduce enquiries to municipal staff, but only when the information is reliable. An automated status display disconnected from the actual workflow may create more frustration than no tracker at all.
The first services should be selected by volume and friction
Cities often begin with services that are technically easy to digitise or politically attractive to announce. A better sequence starts with the procedures that generate the greatest burden for residents and employees.
High-volume services offer the clearest opportunity to reduce repetitive work. Processes with frequent errors, repeated document requests or heavy telephone traffic may create greater value than services used only occasionally. Procedures involving several departments can demonstrate whether the city’s systems can work together rather than merely producing another online form.
Not every service should be placed in the app immediately. Complex cases requiring sensitive judgement may benefit first from better internal case management rather than full self-service. A poorly designed digital route can make these procedures more difficult for residents and employees alike.
The municipality should establish baseline measures before launch: current processing time, number of contacts per application, error rate, staff effort and completion rate. The same measures can then show whether the digital service has improved the process.
Without operational metrics, the city risks evaluating success through the existence of the app rather than the quality of the service.
Employees must be part of the redesign
Administrative digitalisation is often discussed as a resident-facing project, although municipal employees experience many of its consequences.
A new app can increase workload when it creates another intake channel without replacing existing ones. Staff may need to monitor separate systems, transfer data manually and explain discrepancies between what residents see and what internal software records.
Employees who handle applications understand where delays and repeated errors occur. Their knowledge is necessary when redesigning workflows, defining exceptions and deciding which checks can be automated safely.
This involvement should not amount to asking staff to approve a finished system. They need to participate while the process is being mapped and tested. The aim is to remove unnecessary work without eliminating the professional judgement required in complex cases.
Training must also address the complete service, not only the interface. Employees should know how digital identity works, what residents can see, how messages are returned and who is responsible when a case moves between departments.
An app designed without the people who administer the services will reproduce organisational misunderstandings in software.
The city app is the final layer, not the first
A successful city app can make government considerably easier to navigate. It can provide a single identity, a secure postbox, comprehensible application tracking and access to services organised around residents’ lives rather than municipal structures.
None of those benefits comes primarily from the icon on a smartphone. They depend on authoritative data, reusable digital identity, interoperable systems, redesigned procedures and clear responsibility across departments. They require procurement that prevents dependency, privacy rules that residents can understand and support channels built on the same processes as the digital service. Cities that begin with the interface may produce something visible quickly. They are also likely to encounter the same obstacles that fragmented public administration has accumulated over decades.
The stronger approach is less immediately impressive. It starts by mapping processes, removing duplication and agreeing how systems will exchange information. Once those foundations exist, the app becomes useful because it presents a functioning administration rather than attempting to compensate for one that has not changed. The city app may become the new front door to government. The public value lies in what happens after a resident walks through it.
