product design v0.2

Below is a tight product-design articulation, organised around the three surfaces you named and written as something you could hand to an investor, partner, or senior engineer.

Overview

The product is a hosted publishing platform for data, analogous to Substack for writing: opinionated, constrained, and end-to-end. Users do not “build” data portals; they publish data posts inside a data publication. The value is simplicity, distribution, and monetisation, not flexibility.

Design principle

Across all surfaces, the governing principle is constraint. The platform deliberately narrows what can be published and how it appears, so that publishing data feels as effortless and legible as publishing a blog post. The product succeeds if “dropping a dataset” feels as natural as “writing a paragraph.”

1. Sign-up and creation (publisher experience)

Entry A user signs up with email or OAuth. On first entry, they are prompted to create a data publication.

Create a data publication A publication has: – name – short description – optional cover image – default visibility (public / private)

This creates a permanent home (e.g. publication-name.domain), with no further setup required. No subscriber import or migration is assumed at MVP.

Publishing a data post A data post is the atomic unit. Creation is constrained and fast.

Minimum fields: – title – short description – primary data source

Primary data source (v1): – connect a Git repository (default branch, optional path) Future: direct CSV upload, URL ingestion.

On publish, the system: – snapshots the dataset – generates previews (table, inferred charts, schema) – creates a canonical URL – optionally emails subscribers

Posts are immutable snapshots by default; updates create new versions.

2. Social layer (reader and network effects)

Discovery Users can browse recent and popular data posts and publications. Discovery is driven by follows, likes, and lightweight tagging.

Liking Any signed-in user can like a data post. Likes are public signals used for ranking and social proof.

Following and subscribing Users can: – follow a publication (free) – subscribe to a publication (paid, if enabled)

Following adds posts to a personal feed and optional email digests.

User activity surface Each user has: – a feed of followed publications – optional view of liked posts (secondary, not core)

The social layer is deliberately minimal: no resharing mechanics, no threaded discourse at MVP.

3. Getting paid (monetisation)

Publication-level subscriptions Monetisation is publication-centric, not post-centric in v1.

A publisher can: – enable paid subscriptions for a publication – set a monthly or annual price – mark posts as free or subscribers-only

No per-dataset pricing initially; this keeps mental models simple and aligns with Substack’s proven structure.

Payments Publishers connect Stripe to receive payouts. The platform takes a fixed percentage (e.g. 10%) automatically before payout.

Pledges Before enabling payments, users can “pledge to subscribe.” This functions as demand signalling and audience building without friction.

4. Analytics and feedback (publisher dashboard)

Each publication has a simple dashboard showing:

– subscribers (free vs paid) – new subscriptions and cancellations – post views and dataset downloads – basic engagement (likes per post)

Notifications

Publishers receive lightweight notifications: – new subscriber – new paid subscriber – notable engagement milestones

Analytics are descriptive, not optimisation-heavy; the goal is reassurance and feedback, not growth hacking.