Service · App development

Custom open data app development.

A custom app that lets you visualise, compare and openly share open data from government, EU and academic sources with your users. Built for data journalism, policy monitoring, civic tools, replicable research and business intelligence on public datasets. Built on transparent pipelines, with code ownership and no vendor lock-in.

PDOK & CBSEurostat & OECDOpenStreetMapINSPIRE-compliant

Arrange an introductory call See our work

Open data is everywhere — making it usable is the real work.

The Dutch and European governments publish an impressive stream of open datasets: PDOK for geographic data, CBS for statistics, Open Spending for government finances, Eurostat for European figures, the EU Open Data Portal for everything the Commission releases, INSPIRE for spatial information and the OECD for international comparisons. There are also community-driven sources such as OpenStreetMap, Wikidata and Common Crawl. Each dataset is technically accessible on its own, but a working app requires far more than the download link.

The gap lies not in the data, but in what happens between the data and the user. A CBS table with 87 columns and code numbers instead of labels is publicly available, yet practically unreadable for a local councillor. A PDOK WMS delivers raster tiles in RD New projection that must first be transformed before they can appear on a mobile map. Between "this data is public" and "a citizen, journalist or policymaker can do something with it" lies a great deal of engineering work that nobody will do for you.

We build custom open data apps for organisations that want to bridge that gap: a data journalism team, a research institute that wants to distribute replicable research, a policy body that wants to show air quality or the energy mix in real time, a municipality that wants to turn its open data into a citizen tool, or an NGO that wants to make government spending accessible. The work is always the same: scraping, structuring, normalising, integrating, validating and presenting, in an interface suited to whoever is looking at it.

Open data touches several disciplines within our practice. It overlaps with our broader app development, with our experience in geographic apps for spatial open data, with our data engineering platforms as the underlying ingestion layer, with our BI and dashboard tooling for the visual side, and with our projects for software for municipalities. A good open data app draws on elements from all of those areas.

Three common forms.

Which form suits your organisation depends on your audience (journalists, policymakers, citizens, researchers, internal staff), the nature of the source data (static, periodic, real-time) and how much interaction you want to offer (reading, comparing, downloading, acting). In the first conversation we advise which variant will deliver the most value.

Compact project · fixed sprint budget

Data journalism and civic tool app

An interactive mobile or web app that makes open data from CBS, Eurostat or a municipality understandable to a broad audience. Think of a property search app based on BAG, a local air quality tool using RIVM data, a comparison of Dutch municipalities based on CBS figures, or an interactive, browsable version of a research report. Always with an accessible interface, in your brand style, and with a data structure that stays reliable when the next dataset update arrives.

CBS & PDOKAccessible (WCAG)Mobile-firstEmbeddable

Mid-sized project · fixed sprint budget

Policy monitoring and real-time dashboard app

For government bodies, environmental services, NGOs or stakeholder platforms that want to display current public data: air quality, energy mix, traffic flows, water levels, climate indicators, municipal spending, EU funds. The app continuously pulls data from official APIs (Luchtmeetnet, ENTSO-E, NDW, Open Spending, Eurostat), validates and harmonises it, and presents the results in a dashboard that both policymakers and interested citizens can follow, with alerts when values exceed thresholds. For the heavier data layer beneath such an app, we often connect to our data engineering platform practice.

Real-time APIsAlertsComparisonsOpen Spending

Larger project · fixed sprint budget

Research and BI platform on open data

For researchers, policy economists, journalists or analysts who want to structurally combine open data with their own data, for replicable research, longitudinal studies, sector comparisons or pre-deal due diligence. A platform with a query layer, a visualisation layer and a publication workflow, built on a proprietary data warehouse into which OECD, Eurostat, CBS, INSPIRE and Common Crawl data arrive through version-controlled pipelines. With code notebooks alongside charts, transparent methodology and exportable dataset snapshots so that others can reproduce the work. There is considerable overlap with our BI tool practice.

DuckDB & ParquetReproducibleFRBR attributionNotebooks

What an open data app can do as standard.

The functional layers that recur in almost every open data project, whether you have a journalistic tool, a citizen app or a policy dashboard in mind. Each time, we adapt this foundation to your sources, your audience and your existing infrastructure.

Multi-source ingestionPipelines to PDOK, CBS StatLine, Open Spending, Eurostat, OECD.Stat, the EU Open Data Portal, INSPIRE, OpenStreetMap, Wikidata, Common Crawl and sector-specific sources such as Luchtmeetnet, ENTSO-E, NDW and the KvK Open Data. For each source, the right authentication, rate limiting and retry logic. We catch changes to source APIs with version checks, so your app doesn't quietly stop working.
Handling vector, raster and tabular dataNative support for GeoJSON, GeoPackage, shapefile, GeoTIFF and CSV with coordinates for spatial data; JSON-stat, SDMX, CSV and Parquet for statistical data; RDF and SPARQL for linked open data from Wikidata or the Kennisbasis. Large datasets are split via vector tiles or a DuckDB layer so the app stays smooth on phones and on slower office networks.
Version-controlled data snapshotsOpen data changes: a CBS table gets a revision, a PDOK dataset is reclassified, a Eurostat series is withdrawn. We store each ingestion run as an immutable snapshot, with checksum and timestamp, so a report from last quarter remains reproducible. This is especially critical for research, journalism and legal proceedings, where the statement "these figures were correct at that time" must hold firm.
Normalisation and harmonisation layerOpen data rarely arrives in a format suitable for direct presentation. CBS uses its own code tables, Eurostat uses NUTS regions, OECD uses ISO country codes, and INSPIRE has its own vocabularies. We map all codes to a single internal model, provide labels in both Dutch and English, and harmonise time dimensions (years, quarters, weeks) so that data from different sources is genuinely comparable. Mapping it properly once saves hundreds of ad hoc lookups later.
Visualisation and interaction layerCharts via Plotly, Observable Plot, ECharts or D3, depending on your aesthetic and interaction needs. Vector maps via Mapbox GL, MapLibre or Leaflet on top of OpenStreetMap or PDOK tiles. Tables with filtering, sorting, group-by, drill-down and export. Users can save subsets, share them via URL or embed them in articles, dashboards or policy documents, without having to download the underlying data.
Data attribution and source trailFor open data apps, traceability of the source is not a nice-to-have but a prerequisite: for journalistic integrity, for scientific citability and for the Open Government Licence. Every visualisation and every export shows the exact source, the ingestion timestamp, the licence terms and any methodological footnotes. We work to an FRBR-compliant attribution model, so a user always knows which version of which dataset sits beneath a chart.
GDPR-compliant handling of open dataOpen data sounds harmless, but it regularly contains personal data or data that becomes identifiable in combination. An open BAG address dataset combined with a municipal permit database can identify individuals; CBS data at small neighbourhood level sometimes falls under statistical confidentiality. We build disclosure control and aggregation thresholds directly into the app, with logging of which data was provided, to whom and at what level of aggregation, in line with the GDPR and the Dutch Open Government Act (Wet open overheid).
WCAG and EAA accessibilityFor public and citizen-facing apps this is mandatory under the European Accessibility Act (EAA) and the Dutch Tijdelijk besluit digitale toegankelijkheid overheid. We build visualisations with text alternatives, a high-contrast mode, screen-reader-friendly charts and keyboard-only navigation. For data-journalism embeds we also test against the accessibility standards of the publisher where you publish.
API gateway and public data layerYou often also want to expose a structured API yourself, for your research network, for other journalists, for partner organisations or for the civic tech community. We build a gateway with rate limiting, API keys, OpenAPI documentation and a data catalogue, so others can build on your work just as you built on the government data.
Embed and share flowsOpen data apps come alive when their visualisations appear in articles, policy papers and social feeds. We build embed blocks with a responsive layout, a static fallback for anyone blocking JavaScript, OpenGraph cards for sharing on LinkedIn and messaging apps, and version-stable URLs that won't break when you develop the app further later. We deliberately do not use embeds for the former Twitter/X platform.
Maintenance contract (optional)Ongoing maintenance, monitoring of source APIs and further development. Open data apps more often than regular apps require maintenance because their sources keep changing: a revised CBS table, a new NUTS level. We keep track of what is happening with the source owners and adapt the pipelines before your app breaks.

When an open data app is the right choice.

Not every piece of work with public data needs its own app; sometimes a notebook, a Google Sheet or a Tableau dashboard is enough. Six signals where custom open data software truly pays off.

Audience

Users are not data experts

Your audience is a journalist, a councillor, a resident or a general interested reader, not an analyst with R, Python or Power BI in the background. A raw CBS table or a Eurostat API is unusable for them; they need an interface that presents the data in everyday language and in everyday questions.

Recurring

The data changes periodically

You are not publishing a report just once; you want the insights to update automatically with each new dataset release. A static infographic would have to be recreated monthly or yearly, whereas an app pulls the current version and recalculates.

Combination

Multiple sources need to be combined

Your insight doesn't come from a single dataset but from setting CBS, Eurostat, OECD and your own data side by side. Each source on its own shows only half the story. An app harmonises the sources and lets the user filter on the common ground, rather than having to work out the joins and lookups themselves.

Reproducible

Methodology must be demonstrable

For academic research, journalism with legal consequences, or policy papers that must be explained to the House of Commons or the European Parliament, every figure must be reproducible: which source, which selection, which calculation, and at what point in time. An app with version-controlled snapshots and a transparent pipeline is then preferable to a notebook or a spreadsheet.

Real-time

Continuously up-to-date information is needed

Air quality, energy mix, traffic conditions, water levels or public transport delays: if users want to know the value right now, a report or a manually updated dashboard cannot deliver that. A live app queries the source APIs the moment the user looks and raises alerts when thresholds are crossed.

Distribution

Insight must be widely shared

You want colleague researchers, journalists or citizens to be able to work with your analysis: not just view the final result, but also create subsets, apply filters, download data and make API calls. A bespoke app with an embed and API layer is then more natural than a PDF report or a Tableau Public page.

How an open data app project unfolds.

Introductory meeting and source inventory

A conversation to sharpen the intended use: who will look at the app, with what questions, and what decision follows from it. We take stock of the open data sources you already use or would like to use (PDOK, CBS, Eurostat, OECD, Open Spending, INSPIRE, OSM) and check licence terms, refresh frequency and the stability of each source API. At the end you have an overview of the sources worth using and the sources too fragile for production.

Pipeline design and data modelling

We design the ingestion pipeline: for each source, a fetch frequency, a normalisation step and a target model. We model an internal data schema that works logically across the sources, for example a shared region table in which CBS municipalities, Eurostat NUTS regions and INSPIRE codes sit side by side. We test the schema with your data team and with two or three end users through interactive wireframes before we start building.

Building in sprints

Each sprint we deliver a working version on a staging environment. We start with the ingestion and normalisation layer plus one primary visualisation, such as a map or a comparison table, so you can test with real data as early as possible. We then build the remaining views, embeds, alerts and the API layer. You test along with us, end users test too, and we adjust continuously. At each sprint the scope is evaluated so that further development lands in the right place.

Validation and accessibility audit

Before go-live we validate the figures in the app against the original source. This is an important step, because an error in normalisation or in a join can, with open data, propagate far into publications. We carry out a WCAG and EAA audit for public and citizen-facing apps, a GDPR and disclosure-control review for data that approaches personal data, and a security review of the API layer and the embed mechanism.

Rollout and management

A phased rollout to your audience or stakeholders, with monitoring of source APIs and data pipelines. We alert you when a CBS table changes, a Eurostat series is replaced or a PDOK layer gets a new version. Ongoing development runs through the maintenance contract: many open-data apps grow organically once a new source proves valuable or a new audience emerges, and maintenance accommodates that smoothly without you having to start a new project each time.

Fabian van Dijk Business Developer · Appfront

Frequently asked questions.

The questions clients ask when considering an open-data app.

Which open-data sources can you connect to?

In practice, we work most often with PDOK for geographic data, CBS StatLine and the CBS Open Data Portal for statistics, Open Spending for government expenditure, Eurostat and OECD.Stat for European and international comparisons, the EU Open Data Portal for everything the Commission publishes, INSPIRE for standardised spatial data, OpenStreetMap for map content and geocoding, Wikidata for linked open data, and sector-specific sources such as Luchtmeetnet, ENTSO-E, NDW, KvK Open Data, BAG and BRO. For research projects, we also use Common Crawl and the Internet Archive. If you have a specific source in mind that isn't listed here, almost any open API with a licence can be integrated. We can discuss that in the first conversation.

How stable are open-data APIs, really?

Honestly, it varies. PDOK, CBS Open Data and Eurostat are stable at production level, with versioning and clear change logs. The EU Open Data Portal and some municipal open data portals are less predictable; datasets can be moved, renamed or quietly withdrawn. That's why we always build an ingestion layer with validation, version pinning and our own snapshot archive. If a source API goes down temporarily or introduces a significant change, your app keeps running on the last valid snapshot while we adapt the pipeline.

What about personal data in open data?

Open data is not automatically free of personal data. An open BAG address combined with an open WOZ valuation and an open permits register can identify a specific household. CBS data at small neighbourhood level can, through statistical triangulation, lead to individuals. On every project, we run a GDPR pre-assessment: which combinations of sources could lead to identifiability, which aggregation thresholds are appropriate, and which disclosure controls we apply. For projects with serious privacy implications, we carry out a formal DPIA with your data protection officer or privacy officer. For government data, the Dutch Open Government Act (Wet open overheid) and the re-use regime under the Open Data Directive are also relevant.

What is INSPIRE and do we need to comply with it?

INSPIRE is a European directive that requires public sector organisations to publish certain spatial datasets in a standardised format and with standardised metadata. If you want to offer data yourself, alongside what you consume, for example a citizen tool that enriches government data and exposes it again as an open service, you may fall under INSPIRE. We provide metadata in ISO 19115 format, GML or GeoJSON export, and linking to the Nationaal GeoRegister. For private and research parties, INSPIRE usually doesn't apply, but interoperability with INSPIRE-compliant datasets is often still desirable. For the overlap with geospatial questions, see our page on geographic apps.

What licensing conditions apply to open data?

Most Dutch open data falls under CC0, CC-BY-4.0 or the Open Government Licence. CBS data is generally CC-BY with an attribution requirement, PDOK varies by dataset, and Eurostat has its own open data licence that is broadly comparable in practice. OpenStreetMap data is covered by the ODbL, which carries share-alike obligations for derived datasets. We build attribution and licence notices directly into the app, with the correct source credit for each visualisation and, where the licence requires it, a downloadable data export with the accompanying licence text. That saves a lot of work later in legal reviews.

How do you ensure our app meets accessibility standards?

We build WCAG 2.2 AA in from the design stage, not as an afterthought. For public and citizen-facing apps this is mandatory under the Dutch Temporary Decision on Digital Accessibility for Government (Tijdelijk besluit digitale toegankelijkheid overheid) and, since 2025, under the European Accessibility Act (EAA), which also applies to many private providers. Concrete measures include text-based alternatives to visualisations (a map also gets a structured data table mode), high-contrast and dark mode, keyboard-only navigation, screen reader-friendly charts using ARIA attributes, avoiding colour-only encoding, and captions for any video content. In the final sprint we carry out an audit with an automated tool plus a manual check with a screen reader.

Do you host the app, or do we handle that ourselves?

Either is possible. For public and research organisations we often host in a European cloud (Google Cloud Frankfurt, AWS Frankfurt, or a local provider). Clients with their own cloud tenant: we deploy into your GCP, AWS or Azure environment. The codebase is the same; only the deployment target differs. You are not tied to our hosting, and handover of hosting is part of the final delivery.

Which tech stack do you usually use?

For the app: Flutter or React Native for cross-platform mobile, and Next.js or Astro for web. For data: PostgreSQL with PostGIS, DuckDB on Parquet, and optionally Snowflake or BigQuery for heavy research workloads. For pipelines: Python with dbt and Airflow, or Dagster for more complex DAGs. For visualisations: Plotly, Observable Plot, ECharts or D3, and Mapbox GL or MapLibre for maps. We choose what fits your engineering capacity and source data, not what we happen to be used to.

Can you also build an internal BI tool based on open data?

Yes, and that is one of the most requested variants. Policy teams, communications departments, sales teams in the public sector and consultancy firms often want an internal tool that helps them quickly consult government data for tenders, policy advice or market analyses. We build these as a web app with SSO through your Azure AD or Google Workspace, a query builder on top of an internal data warehouse, and export functions to PowerPoint or Word. This kind of project draws on our experience with BI and dashboard tooling and can also remain purely internal, without a public-facing layer.

How do you handle data quality and outliers?

Open data always contains exceptions: a Eurostat series where zero means "no data" rather than "zero", a PDOK layer with duplicate geometries after a dataset migration, a CBS table where a revision appears only in the footnotes. We build automated validation checks: range, type, completeness and outlier detection. Findings are logged and flagged in the app so that end users can recognise a probable outlier instead of being presented with it uncritically. For research, we report issues back to the data owner.

How do you combine open data with AI or language models?

More and more clients want users to be able to query an open data app in natural language, for example: "show me Dutch municipalities where the housing stock is growing faster than average but the population is declining". We build this as an AI layer on top of a structured query layer: the language model translates the question into a validated query, the query runs against the open data backend, and the result comes with an AI-generated explanation that the user can check. For our approach and responsible use of this, see our page on AI development and the wider practice around AI apps.

Do you work alongside our own developers or data analysts?

Yes, that is more the rule than the exception on open data projects. Many organisations have a data team that handles the analysis side, while we build the app layer, ingestion pipelines and visualisation layer. We work in the same Git repository, align with your data schemas, and do pair programming where it speeds up knowledge transfer. By the end of the engagement, your own team can maintain the codebase fully independently — no lock-in to us as a supplier, because on open data projects transparency and repeatability are where the real value lies.

What if we already have a data engineering platform?

Good news — the route to an open data app is then shorter. We connect to your existing data platform (Snowflake, Databricks, BigQuery, or your own Postgres cluster) and use the data already processed there as a starting point. You then need little or none of the ingestion and transformation layer rebuilt; the focus shifts to the app and visualisation side. If you don't yet have a data platform, we often combine the project with the approach from our data engineering platform practice.

Do you also build open data apps for municipalities or government organisations?

Yes, this is in fact an important part of our open data work. We work with municipalities, environmental services, provinces and implementing organisations that want to make their open data available to citizens, councillors or their own organisation. In doing so, we pay particular attention to INSPIRE compliance, audit logging, administrative accountability, and integration with DigiD or eHerkenning for resident-facing functionality. For the overlap with municipal software challenges, see our page on software for municipalities.

Talk to us about your open data app.

A half-hour introductory call, no obligation. We listen to the story you want to get out of your data, look at the sources you already use or would like to use, and give direction where it helps you, including when the advice is that a notebook, a QGIS publication or a Tableau dashboard will take you further before custom work is worth it. For related topics, see our wider app development, our page on geographic apps, our data engineering platform practice, our BI and dashboard tool approach and our experience with software for municipalities.

Schedule an introductory call Or browse more case studies