What are data apps?

A data app is a lightweight application built directly on top of a company's governed data model, designed to let a department do operations that today live in a shared spreadsheet or a small internal tool cobbled together in a hurry: entering a missing value, correcting an exception, approving a change before it flows into the official numbers. It does not replace reporting, it precedes it: while self-service analytics answers "what does the data say", a data app answers "who is allowed to change it, under which rules, with what trail". What sets it apart from a plain interface builder is where the real value sits: not in the module that draws the input form, but in the data platform underneath, meaning granular permissions, traceability of every change, and definitions consistent with the ones used in official reporting. A polished interface built on top of ungoverned data is just a faster way to introduce errors.

Why it is not just low-code

No-code and low-code tools have made building the interface trivial: forms, editable tables, approval flows assemble in hours, not weeks. But an interface that writes directly to a production database without shared validation rules, without a log of who changed what and when, and without alignment to the definitions of the semantic layer used by reporting, is just an Excel sheet with a nicer interface. Data apps that work inside a company sit on the same governed data foundation that feeds executive dashboards, often through writes synchronized via reverse ETL, so a correction made in the operational app reflects in the official numbers without a second manual step.

An enterprise example, and the new risk it introduces

A finance department that today manages reconciliation exceptions on a shared spreadsheet passed around by email can replace it with a minimal data app: a filtered view of unmatched transactions, a button to flag a correction with a mandatory reason, an approval step before the value re-enters the monthly close. The upside is real: fewer copy-paste errors, full traceability, less time chasing different versions of the same file. But precisely because building one now costs a few hours instead of weeks, the risk shifts: it is no longer hard to create one, it is easy to create fifty with no governance over any of them. The problem stops being "how do we build the application" and becomes "who knows this application exists, who maintains it once the person who built it changes role, and which of these fifty are writing data that ends up, unnoticed, in an executive report".

Why it matters for decision makers

A data app deserves the same rigor as a data product, not the casualness of a disposable internal tool: who owns it, what correctness SLA it offers, how it gets deprecated once it is no longer needed. Without a central inventory and at least periodic review, data app proliferation looks a lot like shadow AI: tools born to solve a legitimate problem that, multiplied without control, become a hidden debt that is hard to map.