Consumer ↔ Marketplace

The relationship that makes the Consumer side commercially meaningful to the rest of QRSETU.

The principle

A Consumer is simultaneously a user of their own QRSETU capabilities and a customer of QRSETU's merchants. One account, two things — never two personas and never two accounts.

Consumer (one account)
   │
   ├── Own identity ......... My QR Setu
   │       └── Consumer features ..... Marriage Biodata, future cards
   │                                   ⛔ NEVER surfaced in the marketplace
   │
   └── Marketplace .......... discovers, hires and buys from QRSETU merchants
           ├── Photographer      ├── Boutique
           ├── Electrician       ├── Real-estate agent
           ├── Event vendor      └── Future merchants

✅ Owner decisions (2026-08-28)

These were open questions on this page. They are now answered and are decisions, not proposals.

1. The vendor↔consumer relationship is a must-have, not a by-product

"Yes, this would be naturally repeat orders, so vendor and consumer relationship is a must-have in QRSETU, and both are part of QRSETU's ecosystem."

A consumer's relationship with a vendor persists beyond a single order. Repeat purchase is the expected shape, not the exception.

⚠ Re-measured 2026-08-28, and this is better news than an earlier draft of this page reported. It said ⬜ new requirement. It is 🟦 extension — the shape already exists in the domain layer and only the storage is missing:

• packages/domain/src/consumer/home.ts:22 already lists saved_and_recent as one of the seven consumer home sections, gated on a presence.hasSavedOrRecent flag (:62).
• packages/data/src/consumerActivity/ exists as a stub-only seam (service.stub.ts; the barrel binds createStubConsumerActivityService).
• get_my_consumer_activity is a forward-declared RPC carrying a check:rpc allowance — the name is the contract, and nothing invokes it yet.

So the consumer home was designed with a vendor relationship in it from the start. What is missing is the table and the RPC behind it, not the concept, the screen slot or the seam.

⚠ One caveat on the allowance's stated reason: it reads "the consumer tier does not exist yet", which is stale — that tier is built. The allowance still holds on its first clause (the seam is stub-only), and the reason text has been corrected.

2. Consumer acquisition is the strategy for making the merchant side sellable

"Onboarding consumers and building a user database is the primary intention, to leverage the marketplace and sell the QRSETU platform to merchants. The marketplace is only feasible and valid when there is demand and supply."

This reframes the entire Consumer section, and it is worth stating plainly:

The consumer base is not a second product line. It is the demand side that makes the merchant product worth buying. A marketplace with supply and no demand is not a marketplace.

So a consumer feature earns its place twice: once for the consumer, and once because it grows the population that makes a merchant subscription valuable. That is a stronger commercial argument than consumer monetisation on its own, and it should lead the business case rather than trail it.

A lead as a first-class object is explicitly FUTURE, not now. No lead entity, no attribution, no consent-to-be-contacted model is in scope. ⚠ Nothing in the near-term design should assume one, and nothing should be built that would make one harder later.

3. ⛔ The hard boundary: consumer features are never in the marketplace

"No PII to be visible beyond the public profile by default, and based on consumer sharing consent as to what should be made public. Consumer features or details such as marriage biodata are not part of the marketplace and never should be. It is personal, and intended to be viewed by the person who has the shared link."

This is the firmest rule in the Consumer section. It resolves the risk this page previously raised by removing it rather than mitigating it:

❌ Never	✅ Always
A biodata appearing in marketplace browse, search, or any feed	The biodata is reachable only by someone holding the shared link
A consumer's marital status transmitted to vendors, in any form	The consumer browses the marketplace as an ordinary buyer
Consumer PII as an input to vendor lead generation	Default is private; the consumer chooses what becomes public
Marketplace ranking or discovery drawing on consumer features	Consumer features and marketplace stay separate systems

⚠ The earlier draft of this page proposed surfacing wedding vendor categories when a proposal is marked "finalised". That idea is withdrawn as written, because it sits on the wrong side of this line if it involves the platform acting on a status the consumer has not chosen to publish. If any timing-aware prompt is wanted later, it must be consumer-side only, consumer-initiated, and transmit nothing to any vendor — and it needs explicit approval rather than being assumed from this decision.

🔍 The deep-link requirement, measured — and the premise does not hold today

The owner's third answer contains a technical requirement:

"If the person is directly opening a link and doesn't have QRSETU installed, then the link will open in the mobile browser; and if the app is already installed then naturally it should open within the app, just like a merchant's Setu Card opens within the app."

The intent is right. The stated precedent does not exist. Measured 2026-08-28:

Measured	Value
app.json → scheme	"qrsetu" — a custom scheme exists
android.intentFilters	null — no Android App Links
ios.associatedDomains	null — no iOS Universal Links
assetlinks.json (Android verification)	absent
apple-app-site-association (iOS verification)	absent
+native-intent route handler	absent

An https://qrsetu.com/… link tapped in WhatsApp opens the mobile browser today, on both platforms, whether or not the app is installed. A custom scheme (qrsetu://) is never triggered by an https link.

What "opens within the app" actually means today, and it is the opposite direction. The merchant path is outbound: the merchant is already inside the app, taps a control, and expo-web-browser opens the real DOM URL in an in-app browser tab (setuCardPreview.ts:36). quickTools.ts:89 states the reasoning: "…the renderer and it is DOM (apps/web). 'In the app' is delivered by expo-web-browser opening the…".

• Exists: app → in-app browser → web page (user already in the app)
• Requested: WhatsApp link → app (user outside the app)

These are different mechanisms. The second is ⬜ new work: App Links + Universal Links, two verification files served from apps/web, and a route-handling strategy.

Recommendation, and it keeps ADR-0019 intact

When the inbound deep link is built, it should hand the URL to expo-web-browser, not to a native screen:

• No second renderer. ADR-0019 fixes one renderer for a public page, and check:parity R8 exists specifically to stop apps/mobile importing card-manifest schemas.
• The PII headers survive. A real browser context keeps no-store and noindex; a native screen would have to re-implement the access-control logic the web route already enforces.
• It matches the merchant precedent, so there is one mental model.
• It is cheap. expo-web-browser is already a dependency.

⚠ And note the priority order. The growth loop depends on the no-install path, because most recipients of a biodata will not have QRSETU. Deep linking improves the experience for the minority who do. It is a refinement, not a prerequisite, and it should not delay the feature.

What is already built

Capability	State
Consumer tier — 6 features, 9 screens, 9 routes	✅ Built
Vendor and item discovery — VendorFeed, VendorView, ItemFeed, ItemView	✅ Built
Ordering — place-public-order, six client call sites	✅ Built
Buyer↔merchant chat — one shared module, same chatService both sides	✅ Built
Collection handover — OrderCode	✅ Built
Web marketplace browse — /marketplace/:category/:city	✅ Built
/marketplace index (Discover)	⚠ Deliberate 404 until Discover ships
Vendor relationship beyond one order	🟦 Extension. saved_and_recent section + consumerActivity stub seam exist; storage and RPC do not
Inbound deep linking	❌ New — see above
ScanVerify	❌ The one unbuilt consumer screen

What must NOT be built early

• A wedding-vendor marketplace inside the marriage feature. Supply acquisition, quality control and disputes are a separate business.
• Matching or recommendation between consumers — the matrimonial-portal business this deliberately avoids.
• Ads or sponsored placement in a consumer feature. ADR-0004's promo_slot fails closed forever pending a compliance profile, and a PII surface is the worst place to open that.