Skip to main content

Build, Open Source or SaaS

The build approach is chosen before the brand. A platform that covers the features perfectly is useless if nobody is there to update it.

Six approaches​

  1. Publish in an existing catalog: a regional, national or university one, or a general one such as Zenodo.
  2. A static site or a Git repository: JKAN, PortalJS, OpenSDG, a static STAC catalog, a repository on GitHub. Details in the part "Publishing Without a Portal".
  3. A section of an existing website, if the site's engine can serve descriptions to machines, not just draw a table.
  4. A cloud service: Huwise (formerly OpenDataSoft), Socrata, ArcGIS Hub, Figshare.
  5. An open source platform on your own infrastructure, with the extensions that cover the mandatory features: CKAN, Dataverse, GeoNetwork, NADA, PxWeb.
  6. A custom build.

Launch and maintenance timelines are in the chapter on deployment.

What to compare on​

  • Whether mandatory features are covered by the core or by a living extension.
  • How many people and how much money per year, including checking extensions at upgrades.
  • Where the data is stored, and whether the organisation's rules allow it.
  • What happens if the provider, the contractor or the only administrator disappears.

When each approach fits​

ApproachFits when
Someone else's catalogthere is little data, no team of your own, and a suitable catalog already accepts your datasets
Static site or repositorydozens of datasets, rare edits, someone who can work with Git
A section of a sitethe catalog is small and the site can serve DCAT or at least schema.org
Cloud servicea launch in weeks is needed, there is no operations team, the data may be hosted by the provider
Open source platformthere is a team or contractor for years, custom fields and independence from a pricing plan are needed
Custom builda mandatory feature is not covered by any platform even with an extension, and there is a team for the whole term

What a cloud service costs​

Almost nobody publishes cloud portal prices, so reference points have to be gathered from public procurement. What could be found as of October 2026:

ServiceWhat is known about the priceWhere it can be seen
PortalJS (Datopian)the open source version is free; cloud plans are 1,188, 3,588 and 14,990 dollars a year, large projects by arrangementthe vendor's pricing page
ArcGIS Hub (Esri)the basic version is included in paid ArcGIS Online licences; Premium is a separate annual subscription, priced by the sales teamthe purchase options page
Huwise (formerly OpenDataSoft)no price list. The Grand Paris Seine Ouest territorial authority signed a 600,000-euro contract in 2025 for hosting, maintenance and services; the UK's West of England Combined Authority paid 42,000 pounds for a year of portal operation in 2026–2027procurement notices
Socrata (Tyler Technologies)no price list. In 2024 Austin approved a contract for the Data & Insights platform that runs the city portal, for up to five years and up to 5 million dollarscity council materials

Sums from procurement cannot be divided by each other: contracts include different services, terms and numbers of users, and the sum is often a ceiling rather than an actual payment. So the decision record contains not "what the neighbours pay" but a commercial offer for your volume. Where to look for comparable contracts: in the European Union, TED; in France, contract data on data.gouv.fr; in the UK, Find a Tender; in the US, city council agendas and decisions; in Russia, the Unified Procurement Information System.

The market for cloud portals exists mainly where paying for a subscription is customary. In other countries, open source is more often installed, or organisations live on the free version of ArcGIS Hub.

A custom build: four questions before starting​

The answers go into a decision record, not into correspondence.

  • Which mandatory feature is provided by neither the core nor a living extension? Name the feature, not "we need something special".
  • Who maintains the system in five years if the author leaves?
  • How will persistent addresses, a dataset licence, a metadata dump and schema.org work in your system? Without them the catalog repeats the typical problem of custom-built sites.
  • What does it cost to leave? See the section "What it costs to leave" at the end of the chapter.

According to the dataportals-registry export (release 1.27.0 of 15 October 2026), custom-built catalogs are about 16%. Among indicator catalogs they are 44%, and only 37% of those have an API. A custom build usually loses not on launch day but in the year it stops being developed.

You usually don't need your own engine​

The temptation to write the "right" catalog from scratch is understandable: ready-made platforms always have inconveniences. But there are dozens of catalog engines, and they have already solved most tasks. Two examples show the price of the temptation.

The World Bank and the OECD. The World Bank has several separate public data systems: an indicators portal, DataBank, a dataset catalog, a microdata library. In 2025 another portal joined them, Data360, with its own programming interface. As observed in May 2026, it publishes indicator data in SDMX format but does not offer an SDMX-compatible interface. The OECD took another path: its Data Explorer runs on .Stat Suite, an open source platform developed jointly by statistical organisations. The OECD's new showcase is a new version of a shared product, not one more system to be maintained alone.

Moldova's geoportal. The national geodata portal geodata.gov.md showed 16 maps and layers in February 2024 and was built separately from ready-made geo platforms, although GeoNode would have given the same portal out of the box. In October 2026 its interface runs on MapStore on top of GeoServer, the very components GeoNode is made of, only without its catalog and layer pages. The catalog meanwhile is kept separately, on the national spatial data infrastructure geoportal. Assembling your own from ready parts is also a custom build: gluing, upgrading and describing the layers is up to you.

A custom build is justified when a feature is needed that no platform has and without which the catalog loses its purpose, and the answer to the first of the four questions above is named concretely.

A middle path: a ready core and your own interface​

Between "take the platform as it is" and "write everything ourselves" there is a stable middle option. Storage for descriptions and files, the programming interface and harvesting from other catalogs are taken ready-made, and the site for people is built separately. This setup is called "headless": the platform's own interface is cut off, and only the core works.

  • The Toronto open data portal is a WordPress site, while datasets, their descriptions and the API live in CKAN. In 2023 the city showed the contents and structure of a dataset, a quality score and code examples on the site; the customisations are published as open source. As of 12 October 2026 CKAN holds about 550 datasets.
  • The Indian Data Portal of the Bharti Institute of Public Policy is a Next.js site on top of its own CKAN. Through the catalog API the site builds filters that CKAN does not have: granularity, sector, update frequency.
  • Canada's national portal open.canada.ca runs on CKAN with a large set of its own extensions, ckanext-canada.

PortalJS is the same idea packaged as a product: a ready interface on top of CKAN or other storage, so you do not have to write your own. More in the chapter on static sites.

The upside is your own interface without losing the standard core: DCAT, harvesting and the API remain the same as on thousands of other portals. The downside is two systems instead of one. Your own site must itself keep persistent dataset addresses and schema.org markup, otherwise search engines will see only the core.

Another option is not to build a portal at all, but to assemble a national search engine over existing catalogs. This is what the Scottish Government did: instead of a common portal it built find.data.gov.scot, which harvests descriptions from dozens of local sources. The analysis is in the chapter on search engines and aggregators, and how harvesting works is in the chapter on federation.

A contractor instead of a team​

A government portal is often built not by its own team but by a contractor under a one-year contract. The risk of this model is that development ends along with the contract, and responsibility for quality gets blurred. Russia's data.gov.ru is a clear example.

  • In 2020 the Ministry of Economic Development terminated a 21.8-million-rouble contract to maintain the portal: almost nothing in the specification had been delivered. The contractor was put on the register of unreliable suppliers. This was reported, citing the procurement system, by the Telegram channel "Akh, etot Minfin" in May 2020; the entries in the procurement system could not be checked from abroad in October 2026.
  • In March 2023 the portal was closed "for review" to be moved to the "Gostech" platform. Work under the contract ran from August 2023 to December 2024 and cost 30.9 million roubles.
  • The new version opened only on 15 July 2025, with 5,826 datasets compared with 26,490 in the last saved snapshot of the old version (February 2022). The old version was closed before the new one was ready, and for more than two years the country had no federal portal.

What follows for the client, whatever the country:

  • the code, descriptions and files belong to the client, and a full dump of them is a mandatory deliverable of every stage;
  • the old version keeps working until the new one is accepted; if a move is unavoidable, datasets are published as an archive and their addresses are kept;
  • work is accepted against working features on the live site, not against a report;
  • the portal has at least one person on the client's side who knows how it works and outlasts changes of contractor.

If there is no such person and there will not be, it is more honest to choose a cloud service or a ready platform with minimal customisation: the less of your own code, the less dependence on whoever wrote it.

Example: your own data marketplace​

The most common custom-build idea, one that fails not because of the code but because of the economics.

Context. An organisation buys data from several suppliers and wants to build a marketplace where suppliers list datasets and buyers find and pay for them. Ready-made open source catalog platforms do not accept payments.

Options. Your own marketplace. A cloud marketplace (AWS Data Exchange, Snowflake Marketplace), if the suppliers and buyers are already in that cloud. An open catalog of descriptions without payment: the contract and delivery go directly between the parties.

Criteria. Where suppliers and buyers will come from. Why the marketplace is better than a direct contract with the supplier. Who pays for promotion while the marketplace is empty.

Decision. An open catalog of descriptions, and a cloud marketplace for sales if one fits.

Why. Data marketplaces live where buyers already are: at cloud providers, at software vendors for traders, at a government that both promotes the marketplace and may be its regulator. An independent supplier showcase would have had to spend on promotion for years. Owners of valuable data are not looking for an intermediary, and buying data is rare and contract-based. Your own marketplace without a ready audience stays empty.

Consequences. No payment system of your own means no support for it. Descriptions are open, so buyers and search engines see that the data exists.

When to review. Suppliers and buyers have appeared who have agreed to work through you, and there is a budget for promotion.

What it costs to leave​

The cost of leaving is calculated before the contract is signed. Otherwise you learn it at the moment you already have to leave.

Add up four items:

  1. The dump. All descriptions and all files, not a selection. Open source platforms and an honest cloud service have an API or a dump. If there is no dump, that is already the answer.
  2. Addresses. A table of old and new addresses, and redirects. DOIs issued in advance reduce this item: the doi.org link moves together with the DataCite record.
  3. People and downtime. Who moves things, how many weeks the catalog is read-only, who writes to users.
  4. Retraining publishers. A new dataset form costs more than it seems from the specification.

A reference for comparison, not an estimate:

Where you are leaving fromWhat is usually expensive
Someone else's catalog or Zenodoalmost nothing to move, if you did not promise your own addresses
Static sitecheap: the files and pages are already yours
Cloud servicethe dump and the change of addresses; read the contract before paying
Open source platformyour own extensions and your own field schema; the files themselves come out easily
Custom buildeverything, if the author did not leave a dump and an address map

Lock-in to a cloud service is visible in procurement too. In 2025 Grand Paris Seine Ouest signed a new contract to maintain its OpenDataSoft portal without a tender: the notice says only the vendor holds the rights to the product and its maintenance. This is legal and honestly recorded, but it means there is nobody left to negotiate the price with after implementation.

The closure of someone else's product hits everyone at once. Nesstar, which many microdata archives ran on, stopped being developed in 2015, and each archive moved its collections on its own; Canada's ODESI chose a new platform and started the move before the old one was switched off. The change of ownership of Socrata is the same class of risk for the cloud. A decision record for a cloud service without a paragraph on "how we will get the data out" is incomplete.

Sources​