EVERYTHING A RESIDENT NEEDS ON THEIR PHONE, AND NOTHING NEW FOR THE COUNCIL TO MAINTAIN..

Platforms

Work > Citizen App

Antrim & Newtownabbey Borough Council came to us wanting a mobile app for iOS and Android. What they actually needed was a way to stop maintaining the same information in four different places.

The Council already published everything a resident might reasonably want. Bin collection days, councillor contact details, local facilities, news, service requests. The difficulty was where all of it lived: A Kentico website, a separate citizen request platform, a GIS system holding the location data, and a communications team keeping every channel in step with the others.

Adding an app to that picture would normally mean adding a fifth place to keep up to date.

CONTACT US

THE PROBLEM

A council app is easy to launch and hard to keep honest.

Content

Content duplication was the real cost, not the build. Every new channel meant another place to update. A change to a collection schedule had to be made in several systems, and the first time one of them was missed, the app would start telling residents something the website contradicted. For a public body, that isn't an inconvenience. It's a loss of trust in the official source.
Unlinked Systems

The authoritative data already existed, in systems that didn't talk to each other. Kentico held the content. Te-Care held citizen requests. ArcGIS held the location of every facility and service in the borough. Each was doing its job properly. None of them was reaching a resident standing on a pavement with a phone in their hand.
User Needs

Residents don't think in departments. Someone who wants to know when their bin goes out, where the nearest recycling centre is, and how to report a broken streetlight is having one conversation with the Council, not three. The channels were organised around how the Council was structured rather than how a resident actually asks.
Clear Information

The useful answers are location-specific. "When is my collection?" and "what's near me?" are questions about a particular address, not the borough in general. Anything that couldn't answer at that level was going to send people back to the phone.
Urgent Messages

Urgent messages had no direct route. When a facility closed unexpectedly or weather disrupted collections, the Council could publish and hope people saw it.

WHAT WE BUILT

What the Council needed wasn't an app. They needed a mobile front end to the systems they already ran, where information is published once and appears everywhere it is supposed to appear.

iOS and Android mobile apps, with a cloud-based management system behind them, and integrations into the platforms the Council was already using so that nothing had to be entered twice.

01. Apps for iOS and Android.

Designed around the questions residents actually ask, rather than the structure of the organisation answering them. Local services, bin collections, councillor information, news and reporting sit alongside each other because that is how a resident encounters the Council.
02. A cloud-based content management system.

The Council's own team publishes and updates content, in real time, without a developer in the loop and without re-keying anything that already exists elsewhere.
03. API integration with the Kentico website.

News and service content flows from the existing website into the app automatically. One update, both channels, no difference between what the site says and what the app says.
04. A live connection to Te-Care.

Residents report an issue from the app and it enters the same queue as every other citizen request. Status updates come back to the handset, so the person who reported it isn't left wondering whether anything happened.
05. ArcGIS data integration for local services.

Facilities, recycling centres, parks and services are plotted from the Council's own GIS data, with directions from wherever the resident is standing. When the GIS data changes, the map changes.
06. Address-level bin collection schedules.

A resident sees their collection days, not a borough-wide table they have to interpret.
07. A push notification module.

Emergency alerts, service disruption and Council updates go directly to residents' devices, controlled by the Council's communications team.

WHAT CHANGED

01.

Residents have a single place to explore local services, check collections, find their councillor, report a problem and receive Council updates.

02.

Content is published once and appears across the website and the app, which removes the duplication that would otherwise have made the app unreliable within days/months.

03.

Service requests raised in the app land in the Council's existing workflow, and residents get status updates back rather than silence

04.

The Council can reach every app user directly and immediately when something urgent happens.

05.

Location-based services work from real GIS data rather than a manually maintained list that ages badly

WHY IT WORKED

The easy version of this project would have been a standalone app with its own content store. It would have been quicker to build and, on launch day, indistinguishable from what we delivered. Very quickly it would have been out of date, because keeping it accurate would have depended on someone remembering to do the same job a fourth time.

We spent the time on the integrations instead. The systems the Council already ran were the right systems, and they held the authoritative version of everything a resident needs. The job wasn't to replace them or copy them. It was to connect them and put a usable interface in front of users.

That's the difference between an app the Council has to maintain and an app that maintains itself from the sources the Council already trusts. It's also why the platform has kept earning its place in the Council's digital estate, and why the same thinking about meeting residents where they are has since carried through into the Council's work on AI-assisted citizen engagement.