Appearance
Consumer — the foundation
Your digital identity. Every life stage.
This page defines what a Consumer is in QRSETU. It is the foundation document for the whole Consumer section: every feature page assumes it, and no feature may redefine it.
WHAT IS BUILT VS WHAT IS PROPOSED
The Consumer persona is not new — it is Category 3 of CLAUDE.md's three-user-categories principle, and a tiers/consumer/ surface is already built. My QR Setu and the consumer identity layer are proposed, not built. Each section below says which.
1. What exactly is a Consumer?
A Consumer is a user who belongs to QRSETU's target marketplace audience.
They are a person using QRSETU for themselves. Not a business, not a tenant, not a seller.
The platform already defines this precisely, and the definition is stronger than "someone who browses":
| Property | Source |
|---|---|
| Zero workspace memberships — the defining structural property | tiers/consumer/README.md; CLAUDE.md three-categories table |
| "A completely different dashboard and feature set" — not a reduced merchant view | CLAUDE.md, Category 3 row |
| Anonymous-first is a hard requirement — a vendor card must be fully usable with no account | CLAUDE.md; tiers/consumer/README.md |
authenticated means the logged-in general public, and will be the largest population on the platform by orders of magnitude | CLAUDE.md's threat-model note |
| Category is the DEFAULT EXPERIENCE, never a permanent exclusion — a consumer who later starts a business gains a workspace membership, never a second account and never a data migration | CLAUDE.md |
⚠ A correction to an earlier draft of this section. It split the Consumer into "consumer as buyer" and "consumer as subject" and treated the second as new. That was wrong, and it is the mistake this page exists to prevent: CLAUDE.md's Category 3 already says a consumer has their own dashboard and feature set. The consumer was never only a buyer. What is missing is not the persona — it is the identity and publishing half of it, which has not been built yet.
2. Why does QRSETU have a Consumer persona at all?
Because the platform's growth mechanic depends on it. A vendor's Setu Card is scanned by people who have no business and no account. If those people were a dead end, every scan would terminate. Instead:
- they are the demand side of the marketplace the vendors sell into, and
- they are the population from which future merchants come — the same account, gaining a workspace.
⚠ This is also a threat-model position, not just a product one. CLAUDE.md is explicit: because Category 3 makes authenticated mean the general public, no policy may grant access by ROLE alone. Every merchant-data policy scopes by relationship, and a pgTAP suite must prove a consumer can read nothing merchant-owned.
3. What behaviour do we expect from a Consumer?
Three modes, and a Consumer moves between them freely rather than being assigned one:
| Mode | What they do | Built today? |
|---|---|---|
| Visitor | Scans or opens a link. No account. Views a vendor's card, browses items. | ✅ Built |
| Customer | Buys, books, chats, tracks an order, collects. Account only at the point of intent. | ✅ Largely built — see Marketplace relationship |
| Subject / owner | Publishes something of their own: an identity, a card, a profile. | ❌ Not built. This is My QR Setu. |
The third mode is what the current work adds. It is not a new persona; it is the missing third of an existing one.
4. What is the Consumer's relationship with QRSETU?
Direct, and not mediated by a business. This is the property that makes the consumer side architecturally distinct, and it has one consequence that dominates everything else:
⚠ Every merchant-side abstraction in this platform is keyed to a workspace, and a Consumer has none.
setu_cards.workspace_idisnot null. Feature grants resolve by workspace scope. RLS helpers likemy_workspace_ids()return an empty set. A consumer is not a small merchant; they are a principal the merchant model cannot express.
CLAUDE.md states this as a design rule rather than an edge case: "Any resolver, RPC or policy that requires a workspace to answer a question cannot serve category 3 — that is a design defect, not an edge case."
5. What is the Consumer lifecycle?
Full detail in Lifecycle. In short:
discover → use anonymously → authenticate at intent → own an identity → use features → transact
scan browse a card chat / order My QR Setu marriage biodata, hire a
or link no account OTP, no wall (proposed) future cards vendor⚠ The lifecycle does not end. Individual cards are use-case-scoped and may retire; the account is permanent. That distinction is the subject of Lifecycle and it is the single most important architectural decision on the consumer side.
6. How does a Consumer discover QRSETU?
In priority order, and only the first is built:
- Scanning a vendor's Setu Card or QR — the built path, and the reason the platform exists.
- Receiving a shared consumer card — a marriage biodata forwarded on WhatsApp. Proposed. This is the only discovery channel where the sender is another consumer, which is what makes it a growth loop rather than a funnel.
- The marketplace — searching for a vendor by category and city. Partly built.
- Paid and organic marketing — see the feature-level growth page.
7. How does a Consumer use QRSETU for their own needs?
This is the part that does not exist yet, and it is My QR Setu: a single permanent identity at the consumer's own address, into which they activate individual experiences (a contact card, social links, a marriage biodata, a future life-event card).
The merchant side already has the shape this should mirror — a QR Tools hub where many QR-powered experiences are created, branded, shared and tracked from one place. The consumer analogue is the proposal.
8. How does a Consumer interact with the marketplace?
See Marketplace relationship. The essential point, and it was missing from the first draft of this research:
A Consumer is simultaneously a user of their own QRSETU capabilities and a customer of QRSETU's merchants. Those are not two personas. They are one account doing two things.
9. How does a Consumer become a customer of other QRSETU vendors?
Today: by scanning a card, browsing a catalogue, placing an order, chatting, and collecting. Most of that is built.
Tomorrow, and this is the strategically interesting part: a consumer feature can create marketplace demand. Someone assembling a marriage biodata is, within months, a buyer of photography, catering, venues, jewellery, décor and travel — every one of which is a QRSETU vendor category. The consumer feature is not just a growth wedge for consumer accounts; it is demand generation for the merchant side of the same platform.
10. What is the long-term vision?
One permanent consumer identity, many activatable experiences, and a marketplace on the other side of the same account:
QRSETU
│
├── Consumer
│ ├── Identity ......... My QR Setu (the permanent layer)
│ ├── Features ......... Marriage Biodata → future life-event and personal cards
│ └── Marketplace ...... discovers, hires and buys from QRSETU merchants
│
└── Business / Merchant
└── Setu Card, catalogue, orders, marketplace presence⚠ A feature never redefines this structure. Marriage Biodata is a Consumer feature. It is not a persona, not an account type, not a second marketplace, and not the consumer's identity. If a design discussion starts treating it as any of those, that is the error this page exists to catch.
The rules this section holds itself to
- Start from the existing architecture. The Consumer persona, the three-category principle and the anonymous-first rule predate any feature here and are not up for redefinition by one.
- Consumer data is PII and is NEVER indexed. No consumer-side surface is an SEO surface. See Privacy and security for what follows from that, including the caching consequence.
- Reuse before extension; extension before new architecture. Every architecture page must say which of the three it is asking for.
- One account, many cards. Never solve a modelling problem by creating a second account.