PRODUCT

Product boundary: one-page overview (revised)

What this product is

The product is a hosted publishing platform for data, analogous to Substack for writing or a Statista for indie data publishers: opinionated, constrained, and end-to-end. Users do not “build” data portals; they publish data posts (datasets, data-driven stories or data links) inside a data publication. The value is simplicity, distribution, and monetisation, not flexibility. Data posts are first-class, social, subscribable objects, with built-in distribution and monetisation.

The core object is a data publication, which contains a stream of data posts. A data post can take one of a few closely related forms:

  • a dataset-first post (dataset with minimal narrative), or
  • a data story (narrative text supported by embedded datasets, charts, or previews).
  • a data link (a single URL with a title and description)

Both forms share the same constrained structure and publishing workflow. (in fact, from a user perspective there is just a data post and you can just add data files to that if you want a dataset, or a URL if you want a data link).

Across all flows, the recurring job is the same: reduce the cognitive and operational cost of publishing data to near zero, while preserving distribution, social proof, and monetisation.

What this product is not

  • Not a general data portal (CKAN, Socrata)
  • Not a notebook or analysis environment (Jupyter, Kaggle)
  • Not a BI or dashboarding tool
  • Not a low-level storage service

Any functionality that increases configuration, schema design, or presentation choice is out of scope for MVP.

Core user promise

“I can publish a dataset or a data-driven story with almost no setup, and immediately get a clean URL, previews, subscribers, and (optionally) revenue.”

Atomic units

  • Publication: a named, subscribable container with its own URL
  • Data post: a constrained post that combines data and narrative, ranging from dataset-only to story-led

Primary value drivers

  • Extreme ease of publishing
  • Constrained, legible presentation of data and stories
  • Distribution (feeds + email)
  • Social proof (likes, follows)
  • Monetisation (subscriptions)

If you’re happy with this framing, the next step would be to slightly refine the Data posts and ingestion component to explicitly support “dataset-first” and “story-first” variants under a single post model, and then pick that component (or Publications) to spec in executable detail.