PATTERN Cited by 1 source

Data Application Productization¶

When a question or workflow repeats often enough, turning the underlying logic into a simple application saves time and reduces cognitive load across teams. The bespoke-analysis-to-shared-tool arc: a DS or platform engineer answers a one-off question → gets asked again → notices a second team needs the same derivation → wraps the logic in a small application shared across both teams → app accretes users / use cases / becomes load-bearing.

Signal that productization is the right move¶

Multiple teams require the same derivation. If Support, Engineering, and Finance are each running the same cross-system query with slightly different fingers, that query is a product.
The query requires stitching data across schema boundaries. Cross-system stitching code is where ad-hoc analyses accumulate bugs; centralising it makes correctness an engineering problem, not an analyst-by-analyst problem.
Explanations are asked for repeatedly. If people keep asking "why did this number come out this way?" the derivation needs a first-class explanation surface, not a shared-SQL-file answer.
The logic has become canonical. The derivation encodes a shared-ground-truth interpretation of business rules; freezing it in one app prevents rule-drift across teams.

Structure¶

Self-service surface for the repeat-question audience: support engineers, CX, order-management, enterprise specialists, billing / monetisation engineers. Typically not a traditional analytics dashboard — more like a lookup tool ("given this ID, reconstruct the full narrative").
Plain-language output rather than raw numbers when the audience is cross-functional. Figma's Invoice Seat Report compiles the data into a "plain-language explanation of why each charge occurred", not a SQL-style row dump.
Single source of truth for the derivation logic. When business rules change, one code change updates every consumer.
Embedded in existing team operations (Slack app, internal portal, etc.) rather than living as a standalone destination.

Wiki instances¶

Figma Invoice Seat Report (canonical wiki instance) — Figma Billing DS team built this as a bespoke analysis for explaining seat-level invoice charges; productized after multiple teams (Support, Order Management, enterprise specialists, billing + monetisation engineers) surfaced the same need. Pulls together product-usage events + contract metadata + billing rules + past state transitions → plain-language explanation per charge. Now "one of the most-viewed data applications at Figma." (Source: sources/2026-04-21-figma-redefining-impact-as-a-data-scientist)
Figma consistency checkers — same arc, different shape: started as bespoke invariant SQL for the 2025 billing-model refresh → generalised into a framework → adopted across product security, access / identity management, and growth teams. See patterns/consistency-checkers.
Dropbox Dash query platform (sibling arc) — Dash's federated-retrieval-then-indexed-retrieval evolution is a larger instance of the same productization arc applied at the Dash-scale retrieval layer. (Source: sources/2026-01-28-dropbox-knowledge-graphs-mcp-dspy-dash)

Why it's load-bearing in correctness-heavy domains¶

A bespoke analysis is authoritative only for the moment it was run; the next question re-executes the analyst's mental model. Drift is inevitable.
A productized data application versions the derivation, so the question "why does this charge exist?" has a deterministic answer on any given day — and a git log showing when the answer changed.
Engineers stop tracing multi-system event flows manually; customer- facing teams stop relying on analyst-availability to get answers.
As an organisational side-effect, the app becomes the single artefact where business-rule changes are applied, creating a choke- point for review.

Caveats¶

Premature productization is worse than no tool. The decision signal is repeated demand from multiple teams, not "this seems useful." Figma's framing — "when a question or workflow repeats often enough" — is deliberate.
Ongoing maintenance cost is the price of productization. The app must track business-rule changes, schema migrations of upstream systems, and new edge cases. The org that builds the app must own it.
Generalisation before the use case is proven is the common failure mode. Both the Invoice Seat Report and consistency checkers at Figma started as bespoke analyses and generalised only after demand was proven.

Undisclosed (Figma)¶

No user counts, query rates, availability targets, or explicit productization cadence / criteria disclosed.