Product principles

Use this page when priorities conflict. Principles beat preferences.

Decision framework

Ask in order:

1. Whose job is this? Name the persona and the outcome (see Users).
2. Where does it live? Marketing, iOS, backend, docs, or portal — pick one owner (Surfaces).
3. Is the data structured? Prefer typed receipt / line / warranty fields over images.
4. What is the privacy boundary? Auth, wallet bind, and least privilege stay explicit.
5. How do we know it worked? Name a metric or kill criterion (Metrics).

If you cannot answer 1–5, the proposal is not ready for build.

Core principles

1. Shopper clarity first

A feature that confuses the receipt owner is not done. Prefer fewer, clearer states over clever UX.

2. Structured truth over screenshots

Opaque PDFs and photos are fallbacks — the product value is queryable receipts, lines, returns, and warranties.

3. Privacy & least privilege

Identity bind (e.g. UCI / last4) and auth boundaries stay explicit. Never put secrets in client docs, marketing copy, or MDX.

4. Brand discipline

Follow Design language. Docs/product chrome uses charcoal dark surfaces — not purple marketing gradients for dense UI.

5. Measurable impact

ESG badges and eco copy only when backed by real signals (paper saved, CO₂ offset, milestones).

6. Ship the surface that owns the job

Priority bands (working model)

Bands are guidance for sequencing — not a substitute for the decision framework above.

Related

• Feature lifecycle
• Writing for product
• Engineering auth & security