Appearance
Strategy: competitor analysis & market positioning
Read before changing strategy or market claims
- This page · 2. Differentiation · 3. Revalidation · 4. Product gaps. Surface a business opportunity the architecture naturally supports unprompted, argued with its failure mode, never pitched (R-00 standing obligation); it becomes a
QRS-###row, never scope, until it passes the G-D discovery gate.
Purpose: to test the QRSETU product direction against the market as it actually is, rather than against the market the vision documents assume. Authored 2026-08-18 at the product owner's request. This is a living strategic document: it records a position, the evidence behind it, and the triggers that should make us revisit it.
⭐ A whole-product revalidation was run on 2026-08-25 and it is the newest page in this section: Product & architecture revalidation. It re-tests the five verdicts below against a fresh measurement of the repo, corrects six of them, and answers the reprioritisation question this section could not: the primitives the platform has NOT built serve roughly twice as many industries as the ones it has.
Companion pages: Differentiation verdict · Competitive landscape & SWOT · Product gaps & opportunities · Virality & adoption loops · Revenue model vs the target · 12-month priorities · Product & architecture revalidation · Marriage ecosystem: does the loop hold?
Why this section exists, and what it replaces
Before today the entire competitive position of this platform lived in two places, both unusable:
- A four-row table in
overview/product-vision.mdnaming Google My Business, Linktree, Wix/Squarespace and Zomato/Swiggy — on a page carrying a STALE banner, written before the 2026-08-07/08 platform redesign. documentation/00-overview/competitive-analysis.md, which is archived and banner-stamped, argues the position of three products that no longer exist, and predates the standards programme.
🧮 Measured 2026-08-18: ONDC, Justdial, IndiaMART, Khatabook, Dukaan, Vyapar, myBillBook and Petpooja appear NOWHERE in the portal. The only competitor named anywhere current is Zomato / Swiggy / Urban Company, cited in industry scope's F2 test as a reason to exclude an industry — which is a scoping rule, not a competitive position.
The gap this represents, stated plainly
The platform has a rigorously argued architecture and no argued market position. Every ADR asks "can the foundation express this?" and none asks "why would a merchant choose this over the free thing they already use?" That is not a documentation omission; it is the reason the revenue target in revenue-model has no supporting model, and the reason WhatsApp — used by 78% of Indian small businesses — has been treated as a channel to ban rather than a competitor to beat or a rail to ride.
How to read every claim on these pages
The owner's standing rule is that a conclusion asserted where an enumeration was owed is a defect. So every material claim carries its evidence class, and the classes are not interchangeable:
| Tag | Means | What it may be used for |
|---|---|---|
| 📘 Documented | Stated in QRSETU's own current documentation, cited by page | Reasoning about intent and decided direction |
| 🧮 Measured | Produced by a command, a live Dev probe, or a repo grep in this session | Reasoning about what exists |
| 🌐 External | Public market data, with a source link | Reasoning about the market |
| 🔎 Inferred | My reasoning over the three above. A judgement, not a fact | Argument, always contestable |
| ❓ Unvalidated | An assumption with no evidence in either direction | Nothing. It is a research task |
⚠ The single most important line in this section: every revenue, conversion and adoption number on revenue-model is 🔎 or ❓. There is no willingness-to-pay evidence for any QRSETU vertical — 📘 the festival-stall brief's Q21 returned NA, and 📘 the direct-seller brief records willingness-to-pay as explicitly open. A financial plan built on 🔎 is a hypothesis with a spreadsheet around it, and it must be labelled as one.
The commercial baseline, measured — read this before any projection
🧮 Probed live on qr-setu-dev (dyhjofjjuazhyqcvlrkx) on 2026-08-18, 27 days before Ganesh Chaturthi (14 September 2026):
| Rows | What it means commercially | |
|---|---|---|
users | 7 | The whole platform population |
workspaces | 5 | Five businesses exist |
setu_cards | 5 | Five cards exist |
catalog_items | 6 | Six things are for sale, platform-wide |
media · catalog_item_media | 0 · 0 | ⚠ There is not one product photograph on the platform |
setu_card_links · setu_card_hours | 0 · 0 | No card carries links or opening hours |
orders · payments | 19 · 18 | Real money has moved. The loop works |
workspace_subscriptions | 1 | One paying workspace. ₹9,999 of booked revenue |
conversations · messages | 0 · 0 | Chat is deployed and unused |
| any analytics table | does not exist | ⚠ Nothing is measured. See below |
| any reviews/ratings table | does not exist | ⚠ No reputation capability at all |
parties · schedules · ledger · balances · assets · campaigns | do not exist | Six of eleven primitives have no substrate |
🧮 And one new defect found while assembling this baseline, logged as QRS-734: the public Setu Card's analytics beacon posts every view to track-card-event, which lives only in supabase/functions/_archive_pre_v2/. A live list_edge_functions probe returns exactly nine ACTIVE functions on Dev, and track-card-event is not among them. navigator.sendBeacon swallows failures by design, so every card view has been recording nothing, silently. The one number QRSETU needs in order to sell anything to a merchant — "your card was opened N times" — is not being collected.
Read the baseline as good news about the code and bad news about the clock
The backend is genuinely further along than the market position is. Five cards, six items and one subscription is not a failure of engineering; it is the measured distance between "the platform can do this" and "merchants are doing this". Every page in this section is about closing that distance, and almost none of it is a schema problem.
The five verdicts, in one place
| Question | Verdict | Where argued |
|---|---|---|
| Is QRSETU genuinely differentiated? | Partly, and not where the documents think. The differentiation is real but currently architectural and invisible to a merchant. The customer-visible differentiation is thin, and the one genuinely unserved wedge (seasonal high-volume vendors) is correctly chosen and under-exploited | differentiation |
| Who are the real competitors? | Not Wix and Linktree. WhatsApp Business, Google Business Profile, Justdial and ONDC — three of them free, all four already holding the audience QRSETU is trying to build | competitive-landscape |
| What is missing that would matter? | Reputation, one measurable proof point, catalogue ingestion at scale, and working notification transport. None is a new primitive; three are days of work | product-gaps |
| Can it grow virally with two people? | Yes, through four loops — and the strongest is merchant-to-merchant, not consumer-to-consumer. The in-app marketplace is the weakest available loop and is being built first | virality-and-adoption |
| Is ₹1.25 Cr by August 2027 achievable? | Not as cumulative gross revenue on the current direction. Honest range ₹23-77 lakh, midpoint ~₹45 lakh. It becomes achievable if restated as an exit run-rate, or if a reseller/association channel lands by November 2026 | revenue-model |
What this section says should CHANGE
Listed here because the owner asked for the analysis to challenge the direction rather than justify it. Each is argued on its own page; this is the index.
| # | Change | What it contradicts |
|---|---|---|
| C1 | Stop treating WhatsApp as a competitor to exclude. Ride it as the share-and-notify rail | 📘 the Marketplace spec's "No WhatsApp CTA" constraint |
| C2 | Sequence the public SEO directory BEFORE the in-app marketplace | 📘 the current build order: the in-app consumer tier is 10 of 11 screens built and the public directory is not started |
| C3 | Add a reputation capability. Reviews clear the ≥3-industry gate several times over and no table exists | 📘 the closed eleven-primitive set |
| C4 | Make the MLM upline the first enterprise motion, not the car dealership — ⚠ re-tested 2026-08-22 against eleven external research tracks and UPHELD, with two of its own reasons corrected: see verticals/car_sales/ | 📘 industry scope calls the dealership "the flagship Enterprise case" |
| C5 | Price a recurring plan now. 🧮 platform_plans.pro.price_minor is NULL and the only priced plan bills once per festival season | 📘 the launch decision to ship one seasonal plan |
| C6 | Treat the 5% commission as upside, never as a revenue line | Nothing — 📘 QRS-489 already concluded this. It should be made official |
| C7 | Answer ADR-0004's open question NO for this horizon, and drop profiled advertising from the plan | 📘 QRS-533's parked-but-highest-priority framing |
| C8 | Sell done-for-you catalogue setup as a product line | Nothing. It is absent from every document and is the highest-conviction revenue available |
Revisit triggers — this page is stale when any of these fires
A living document needs a condition, not an intention. 📘 The delivery log's own review trigger was passed at 26 entries and never actioned, so these are written as observable events:
- Ganapati 2026 closes (after ~25 September 2026). The season produces the first real willingness-to-pay, conversion and online-share numbers. Every 🔎 on revenue-model should become a 🧮 within two weeks of season end.
- QRS-489's pre-committed rule resolves — if online GMV share is under ~10%, commission stops being a revenue line anywhere in this section.
- A priced recurring plan collects its first rupee. Until then every year-round projection is 🔎.
- A competitor named on competitive-landscape ships into our wedge — specifically: WhatsApp catalogues exceeding 500 items, or Justdial extending its SME management suite to seasonal vendors.
- The reseller channel reaches 10 active resellers, or fails to by 30 November 2026. Either outcome changes twelve-month-priorities.
- Headcount changes. Everything here is prioritised for two people. A third pair of hands, or one fewer, invalidates the ordering rather than merely accelerating it.
What this section deliberately does NOT do
- It does not re-derive the architecture. ADR-0020..0027 are not questioned on their engineering merits. Where a decision carries a commercial consequence the documents do not name, that is said.
- It does not produce a marketing plan. Channel mechanics appear only where they change what to build.
- It does not validate the market. 🌐 figures here are public and second-hand. ❓ Every India-specific conversion, price-sensitivity and category-demand assumption remains unvalidated, and revenue-model lists the research that would close each one.