In many organizations, the same information lives in several places at once: on the website, in a mobile app, in the newsletter, on a registration page. As long as these are maintained separately, every change means doing the work several times, and sooner or later they drift apart: one place already shows the new value, another still shows the old one.
What's needed then isn't another interface, but a single owner for the data.
The data lives in one place
The principle is simple: we manage the data in a central admin interface and serve every other interface from there through an API. The website, the app and the newsletter don't each keep their own copy of the same information. They work from the same source and display it in the way that suits their own purpose.
If something changes, it has to be changed in one place, and the change shows up everywhere.
One event series, four interfaces
One of our clients regularly organizes multi-day programs that run across several venues or rooms. For these, we built a shared system where rooms, talks and speakers are all managed in one place.
Several interfaces work from this same data source:
- Mobile app with a digital program guide, notifications, automatic updates and offline support.
- Content website, where interviews and related articles appear alongside the event's topics.
- Registration site, which lists the program from the same source and handles ticket types, accommodation, dates, restrictions and invoicing.
- Newsletter system, which works from everyone who signed up at any point in the process, and syncs its content from the related pages.
With this setup, launching an event took only a short technical configuration and then uploading the content. And when a new interface was needed, it was ready in days, because the data and the API were already in place.
The data model is the most critical part
In a system like this, the interfaces can be built quickly. The real task is designing the data model: what depends on what, what can change independently, and how an event or any other data can be described so that every interface can display it, even when a mobile app needs to highlight something completely different from a registration page.
If this is done well, new requirements rarely call for a major development project. Most of the time, it's enough to extend an existing endpoint or build a new view.
A single website doesn't need a central data source
This approach isn't the right answer in every situation. If it's a single website and the content rarely changes, a central data source and an API mean extra work that rarely pays off. We usually recommend centralizing when the same information lives on several channels, changes often, or recurs regularly: programs renewed year after year, parameters used in several places, content shown on several interfaces.
Interfaces come and go
A website becomes outdated within a few years, an app gets redesigned, and instead of the newsletter you may need to focus on a different channel. Well-designed data, however, stays. If instead of building individual interfaces we put the data behind them in order, a new channel no longer means a new project, just a new view.
If you also have to maintain the same information in several places, let's start with a map: where the data lives today, who changes it, and which system should own it. From there, it becomes clear how much work can be saved.