Key takeaways
- An open data portal must do eight things: a catalogue, dataset pages, open formats, an API, a licence, versions, a methodology note and a last-updated date.
- CKAN, the open-source portal platform, covers the catalogue, licences, previews and an API out of the box. You still pay to host, run and upgrade it.
- A custom build earns its cost when readers come for answers and charts, not files, or when the portal must sit inside your own site.
- A middle path works well: CKAN as the catalogue behind a custom front end that reads its API.
- Decide who refreshes each dataset before launch. A portal with stale data does more harm than no portal.
“Which platform should we use?” and “who keeps it updated?” are the two questions every open data project hits first, usually in that order, and the second matters more. A research institute, a government department or a programme team decides to publish its data properly, and the first conversation turns to tools. This guide starts one step earlier: what a portal has to do, then how CKAN, a hosted platform and a custom build compare at doing it, what the publishing workflow looks like, and how to make the data useful to people who will never download a file.
What must an open data portal do?
An open data portal must let people find a dataset, understand it, get it in an open format, reuse it legally and trust that it is current. Everything else is presentation. In practice that means eight things, and check your plan against all eight: leave one out and the data can be online while nobody can use it with confidence.
Check the last two first when you plan, because they decide whether your data gets cited. A researcher who can’t tell which version of a dataset they used, or can’t find the note that explains how an indicator was calculated, will cite it carefully or not at all.
Should you use CKAN, a hosted platform or a custom build?
Use CKAN when you publish many datasets and the catalogue is the product; use a hosted platform when you want a portal without running software; build custom when readers come for answers, charts and explanations more than for files. The table compares the three on what decides the choice.
Planning a data portal?
Tell us what data you publish and who uses it, and we’ll talk through whether a catalogue, a custom portal or both fits.
A few facts behind the CKAN column, from its own documentation. CKAN describes itself as “a tool for making open data websites”. Data is published as datasets, each with metadata and one or more resources (the files or links), owned by an organisation that manages its own publishing workflow and user roles. A licence is chosen for each dataset from a list, CSV and Excel files get a grid preview, and each dataset has an activity stream that shows its recent changes. Its optional DataStore loads tabular files into a database, so people can read, search and filter the data through the API without downloading the whole file. The code is on GitHub under the GNU Affero General Public License v3.0, and ckan.org lists government portals such as data.gov, data.gov.au and opendata.swiss among its users (all checked 20 October 2026).
There is also a fourth path that the table doesn’t show as a column, because it is a mix of two: CKAN as the catalogue, with a custom front end. CKAN holds the datasets, the licences and the API; your own site reads from that API and adds the design, the charts and the explanations. You get a proven catalogue and a reader experience of your own, at the cost of running both.
What does the publishing workflow look like?
The publishing workflow takes each dataset from a file on someone’s laptop to a public page in six steps: prepare, describe, review, publish, refresh and retire. The platform matters less than whether these steps are written down and owned. Without them, the first release is careful and every later one is rushed.
Who keeps the data up to date?
A named person for each dataset keeps it up to date, with the refresh written into their work, not left to whoever remembers. Decide this before launch, because it shapes what you build:
- Where the source publishes on a schedule or through an API, automate the refresh, and alert someone when it fails or the format changes.
- Where the data comes from your own analysts, make the upload simple enough that they can do it without a developer, with the same checks every time.
- Show the last-updated date on every dataset page and every chart, so readers can see how current the numbers are without asking.
- Plan for the day the owner leaves. The workflow above, written down, is what lets the next person carry on.
A portal that launches with fresh data and then stops updating does more harm than no portal: people find old figures, cite them and assume they are current.
How do you make data usable beyond downloads?
Make data usable beyond downloads by putting the answer on the page: a chart and a plain summary on each dataset page, filtered downloads, an API with examples, and short explanations for the findings people come for. Plan for visitors who are not analysts: someone who wants one number, one trend or one comparison will leave if all they find is a download link. Your analytics and search terms will show which questions they bring.
This is where a custom build, or a custom front end over CKAN, usually earns its cost. A catalogue lists datasets; a reader experience answers questions with them. Our guides to presenting research data to policymakers and data storytelling for research teams go deeper on the explaining side.
Which way should you go?
Count how many of the six statements below are true for your project; the more you tick, the more a custom build fits. None of them is a verdict on its own. They tell you where the weight of your project sits: in the catalogue, or in the reader experience.
Tailwebs built the dashboards for CEEW’s Green Finance Centre (GFC): the EV dashboard and Renewables India with the CEA. Both are public dashboards: they track indicators for readers who come back for the same numbers, the format that often sits inside a larger portal. We have also shipped full data portals, with dataset downloads, licences and an API for partners.
For how we plan a portal, from the data audit to who keeps it fresh, see open data portal development. If what you need is mainly charts for a known set of indicators, start with dashboards and data visualisation.