Appearance

Product gaps & opportunities ​

Part of Strategy: competitor analysis & market positioning. Evidence-class legend there.

The organising claim ​

The four cheapest gaps are worth more than every planned feature in the roadmap

🔎 QRSETU's problem is not a shortage of features. It is that the four things which make every other feature sellable are missing, and three of them are days of work.

  1. Nothing is measured — so no value can be demonstrated and no nudge can be grounded.
  2. No message can reach anyone — so no proactive surface can fire and no order can be heard about.
  3. There is no reputation — so a stranger has no reason to trust a card.
  4. A catalogue takes ~50 hours to enter — so the product's core artifact is usually empty.

🧮 Measured today: 5 cards, 6 catalogue items, 0 photographs, 0 conversations, 1 paying workspace. That is not a feature-coverage problem. Meanwhile the roadmap's next large items — the in-app marketplace, campaigns, the org-admin portal — all depend on these four and none provides one.

The gaps are ordered by value ÷ effort, and effort is 🔎 estimated for one developer.

G1 · One measurable number, per merchant, per week 🔴 blocking · effort 1-2 days ​

The gap. 🧮 No analytics table exists in any migration. The public card installs an analytics beacon that posts to track-card-event, which lives only in _archive_pre_v2/; a live probe of Dev returns nine ACTIVE functions and it is not among them. navigator.sendBeacon swallows failures by design, so card views have been recording nothing, silently (QRS-734). Mobile has zero analytics wiring.

Why it is first. 🔎 Three separate things in the plan are unreachable without it, and each is individually load-bearing:

  • The renewal conversation. A vendor asked to pay ₹9,999 again next season will ask what they got. 📘 The Marketplace spec already names the answer — "you appeared in 40 area searches this week" — and calls it "the vendor pitch made checkable instead of rhetorical." Today there is no number.
  • Every proactive nudge. 📘 CLAUDE.md: "never fabricate insight... if the read model can't support a claim, don't make the claim." With no read model, the correct behaviour is silence — so the product principle is fully honoured and fully inert.
  • The pre-committed commission decision. 📘 QRS-489 commits to measuring orders created against orders paid online and deciding by that ratio. 🔎 The rule cannot be applied, so the decision cannot be taken.

The smallest thing that works. Do not build ADR-0010's read model. Ship a minimal card_events table (slug, event, day, count) plus one anon-callable increment, repoint the beacon, and surface one line on the merchant dashboard. 📘 The taxonomy and the client beacon already exist; what is missing is a live destination.

⚠ Keep ADR-0010 D7 intact — counts only, no visitor identifier. 🔎 That decision is also what keeps profiled advertising off the table (see G10), and it should be defended rather than eroded for convenience.

G2 · A working notification channel 🔴 blocking · effort hours to fix email; 2-3 days for a merchant alert ​

The gap. 📘 Remote push does not exist by explicit decision (no entitlement, no token table, no dispatch path). 📘 Email OTP has returned SMTP 535 since ~1 August — a credential problem, not a code problem: Supabase is pointed at one relay while the domain's verified transactional sender is another, and SPF authorises only the first.

Why it is second. 📘 The festival brief states it in one line: "A booking nobody hears about during a four-week season is worse than no booking at all." 🔎 And the consequences are wider than orders — with no transport, sign-in by email fails, order confirmations do not arrive, and every item on the direct-seller engagement layer degrades to in-app only.

The smallest thing that works, in order:

  1. Fix the SMTP credential and merge the SPF include. 📘 One SPF TXT record only, ever — merge, never add a second. This is the highest-value hour available anywhere in the product.
  2. A merchant order alert that does not need push. 🧮 merchant_payment_alert_reads already exists with a server-side watermark for exactly this reason. Deliver on next foreground plus email.
  3. A WhatsApp click-to-chat handoff for the buyer's confirmation — see G4. No API, no cost.
  4. ❓ Then decide push deliberately (token table, dispatch function, paid Apple account) rather than by deferral. 🔎 It is needed for the store ship anyway.

G3 · Reputation — the largest absent capability 🔴 · effort 3-5 days for the funnel; larger for native reviews ​

The gap. 🧮 No reviews, ratings or testimonials table exists anywhere in the repo. Reputation is not among the eleven primitives, and 🧮 the word appears in the portal only in unrelated contexts.

🔎 This is a scope gap rather than a deliberate exclusion, and the ≥3-industry gate clears it several times over: salon, clinic, tutor, electrician, photographer, caterer and boutique all live or die on reputation. A card that says "we are good" with nothing behind it is a poster. 📘 Meanwhile the architecture already documents the harder half — ADR-0026's verification model — so the platform can prove a vendor is registered and has no way to show they are good.

The recommendation, and it deliberately does not build a review graph:

  • Phase 1, and do this one: a Google review funnel. 📘 QR tooling already mints codes. A "ask for a review" code that lands on the merchant's own Google review link, plus a card block showing their live Google rating. 🔎 Merchants pay for reviews. This complements the competitor we cannot beat instead of fighting them (competitive-landscape §5), and it needs no moderation, no abuse handling and no new trust obligations.
  • Phase 2, only if evidence demands it: first-party reviews tied to a completed order. 🔎 An order-gated review is far more defensible than an open one, and QRSETU has the order. But it brings moderation, takedown and defamation exposure that 📘 two people with no moderation tooling should not take on before the grievance obligations already in flight are settled.

⚠ Do not fake it. A "verified by QRSETU" badge that means nothing is worse than an absent rating, for exactly the reason 📘 the material-badge decision already records: a factual statement is the vendor's, a styled badge is the platform endorsing it.

G4 · WhatsApp as the share-and-notify rail 🟡 · effort 2-4 days · ⚠ reverses a documented constraint ​

The gap. 📘 The Marketplace spec's constraints include "No WhatsApp CTA. QR Setu has its own ordering and enquiry flows" and "No UPI promotion", and 🧮 the chat schema's own comment says "QR setu chat REPLACES WhatsApp, so this is the only inbox."

🔎 The intent is sound and the execution is commercially expensive. 🌐 78% of Indian small businesses use WhatsApp for customer communication; 🌐 consumer reach is effectively universal; 🧮 QRSETU's own conversations table has 0 rows while the alternative it was built to replace is where the merchant already is.

The distinction that satisfies both positions:

Keep banningStart using
WhatsApp as the transaction rail — orders must not complete in a chat we cannot recordWhatsApp as the share rail: one-tap share of a card, an item, an order confirmation, a session invite
A bare "chat on WhatsApp" CTA that replaces our recorded inboxA pre-composed status/broadcast image the merchant posts themselves. 📘 The direct-seller brief asks for exactly this ("reusable promotional images, tagged")
Vendor UPI IDs on the card, which route money around usA click-to-chat handoff as the fallback when our transport is down — which 🧮 it currently always is

🔎 Why this is worth reversing a decision for: it is the only available fix for G2 that costs nothing and requires no infrastructure, and it converts the market leader from a competitor into a distribution channel. 📘 The festival brief already records that the card's forward path is a WhatsApp group — "a family or mandal chooses collectively, so the link naturally enters a WhatsApp group" — so the growth mechanic already runs on WhatsApp whether the product acknowledges it or not. Logged as QRS-745.

G5 · Catalogue ingestion at scale 🔴 · effort 1 day for bulk-paste; 5-8 days with AI assist ​

The gap. 📘 The vendor carries 1,400-1,500 items and 📘 QRS-481 estimates ~50 hours of re-entry. 🧮 Six catalogue items and zero photographs exist platform-wide, 27 days before the season.

🔎 This is the actual adoption blocker and it is not a card problem. A merchant who cannot get their inventory in does not have a product, no matter how good the card is. And the reverse is the real risk 🔎 QRS-481 already names: a vendor who lists 80 of 1,500 idols ships a worse buyer experience than their physical stall.

Ladder, cheapest first:

  1. Bulk paste / CSV import with per-row validation. Unglamorous, one day, works today.
  2. Multi-select photo upload that creates draft items — one item per photo, named later. Turns the job from "type then attach" into "shoot then label".
  3. AI-assisted draft extraction: photo → suggested name, height, material, style, price band. 🔎 The four facets 📘 the brief names are exactly what a vision model can propose, and the merchant confirms. This is a genuine differentiator — 🔎 nothing in the Indian SMB catalogue market does it — and it directly attacks the measured #1 blocker.
  4. Done-for-you setup as a paid service (G7). 🔎 Available immediately, needs no engineering, and it is how the first fifty catalogues should actually get populated.

⚠ Cap video per workspace before it is discovered from a bill. 📘 QRS-488 measures per-idol video at ~300× the photo footprint.

G6 · Season archive and one-tap re-open 🟡 · effort 2-3 days ​

📘 The vendor wants the card gone at season end and their stock carried over; 📘 QRS-488 establishes that retaining a full catalogue costs ₹5-73 per vendor per year and that deleting costs more than keeping. 📘 QRS-487 notes festival stall is the one vertical where plan lapse and product intent point the same way.

🔎 So the retention mechanic is nearly free and is currently unbuilt: at next season, "your 1,480 idols are still here, republish?" converts in one tap and removes the 50-hour objection permanently. Without it, year two is a cold start against a vendor who already paid once. 🔎 This is the highest-leverage retention item in the seasonal model.

G7 · Done-for-you setup as a product line 🟢 opportunity · effort zero engineering ​

Not a software gap. A revenue line that is absent from every document.

🔎 The measured blocker is human effort, the marketing person's time is the platform's second scarce resource, and merchants in this segment are accustomed to paying a person to do a digital job. A ₹5,000-15,000 "we build your card and shoot your catalogue" offer:

  • Converts better than the subscription, because it removes the objection rather than arguing with it.
  • Seeds the catalogues that make cards worth visiting, which is the constraint everything else waits on.
  • Produces the reference cards the sales conversation needs.
  • Generates the willingness-to-pay evidence 📘 that Q21 could not.

⚠ It does not scale past two people, and that is fine — it is a bridge to the channel in virality-and-adoption L4, and 🔎 the resellers who eventually deliver it are the same people who would sell it. Logged as QRS-746.

G8 · Public SEO directory before the in-app marketplace 🟡 · effort 4-6 days · ⚠ reverses build order ​

📘 The Marketplace spec is explicit that the two surfaces are not alternatives: "the public web directory is acquisition, the in-app Marketplace is engagement and retention", and that only the first claim is true on day one — "you will be found in searches for your area" is true from the first crawl, while "our consumers will find you" is false until consumers exist.

🧮 The build order is the opposite of that reasoning. The in-app consumer tier is 10 of 11 screens built with a discovery read path landing today; the public directory is not started and 📘 the landing page is still a placeholder.

🔎 Recommendation: publish the directory first. Area and category pages, server-rendered, indexable, long-tail queries nobody optimises for ("ganpati murti Dadar", "tiffin service Kothrud"). It needs no consumer base, it is the only claim we can make honestly, it is the only acquisition channel that compounds while we sleep, and 🔎 five cards is enough to start because the pages grow with supply. ⚠ It also carries a scraping surface and a new access class — 📘 QRS-491 is the constraint, and no policy may be widened to TO authenticated.

G9 · The khata, positioned correctly 🟡 · effort large · ⚠ reprice the expectation ​

📘 Industry scope calls the khata "the strongest product wedge in this entire scope." 🔎 As an adoption wedge that is right. As a revenue wedge it is the most thoroughly falsified hypothesis in Indian SMB software — 🌐 Khatabook reached enormous adoption with near-zero revenue for years and monetised only via lending, and 🌐 both it and OkCredit shut the storefront products they built on top of that adoption.

🔎 The correct reading, and it is not "do not build it": khata is a retention and frequency mechanism. It gets a merchant into the app daily, which is what every other capability needs. Price something else. And note the precedent's sharper warning: the exact sequence QRSETU plans — khata adoption, then a storefront on top — is the sequence two better-funded teams ran and abandoned. 🔎 That does not mean it cannot work; it means the storefront must be valuable for a reason the khata did not supply, which for us is the catalogue depth and the handover loop.

G10 · What NOT to build, with reasons ​

🔎 A gap list that only adds is a wish list. These are live proposals that should be actively declined for this horizon.

Do not buildWhy
Targeted / profiled advertising (📘 QRS-533)🔎 Reverses ADR-0010 D7's counts-only decision, brings DPDP profiling duties, and needs a consumer base that will not exist. 📘 The row itself flags it as running ahead of a decision
Third-party ads on cards (📘 ADR-0004)📘 The brand question has been open since July and compliance_profile does not exist. Answer it "no" for this horizon and stop carrying it as an option
Campaigns engine (📘 ADR-0025)🔎 Excellent design, and its buyer is an enterprise that 🧮 has 0 rows in organizations. Sequence it behind a customer
Org-admin portal for dealerships🔎 A fourth Stack 1 tier needing an ADR-0011 amendment and a design pass, sold into 6-9 month procurement cycles by two people. See revenue-model §3
Multi-template picker🔎 One manifest renders. A second template adds choice paralysis before there is a merchant who wants it
Native reviews before the Google funnelG3 phase 2 brings moderation and defamation exposure. Do phase 1
In-app purchase CTA on native📘 ADR-0002 / Apple 3.1.3(d). Not a preference — a store-review risk
Any workflow engine📘 Industry scope already refuses this on three independent grounds. Keep refusing
White-label, API and developer programmes🔎 The archived go-to-market plan projects ₹3-3.5 Cr from these. It assumes a partner-manager, a developer-relations function and a sales team. With two people these are fiction, and the projection should not be inherited