Appearance
Product Vision
STALE — read current architecture state first (2026-08-08)
Audience model superseded. QRSETU has three user categories (solo business owner · enterprise organization · individual consumer) plus QRSETU staff — see user ecosystem and industry scope. References here to profile_items and subscription_tier predate the ADR-0020 baseline.
Status: DRAFT — core decisions taken 2026-07-14; upper half still to be rewritten to match. This page consolidates the product vision from the legacy
documentation/00-overview/*set (introduction,glossary,business-types-and-services,competitive-analysis,consolidated-analysis,use-cases) into one foundation. Several claims in those source docs contradicted the current codebase andCLAUDE.md; those were reconciled in Vision vs. Current Reality at the bottom. Decisions now locked (2026-07-14): (1) core = 3 pillars + built features; CRM/Finance are roadmap, not core; (2) mobile = Expo / React Native; (3) template-first is core architecture; (4) website-builder canonical schema =setu_*(studio_*is legacy/dead); (5) data-sync = RPC + TanStack Query (from()banned) — the docs' "polling-first" is stale. The remaining open item is sequencing template-first, which is currently greenfield.
Vision statement
Be the proactive business assistant that a small Indian business actually runs on — not a place to store and view information, but a product that continuously identifies opportunities, surfaces actionable insight, and prompts the next meaningful action.
Every merchant gets a Setu Card: their universal public identity at qrsetu.com/<slug>, reachable from a printed QR, opening instantly in a customer's phone browser with no app and no account. Around it sits the operating layer they need for their line of work — catalogue, orders, enquiries, bookings, reminders, analytics — shown only when it applies to them.
Mission
Simplify digital adoption for small-business owners and entrepreneurs with an intuitive, lightweight, affordable product — digitize their offering, let customers reach them from a QR scan, and run operations with minimal admin overhead, for a user who may be holding a phone in one hand and serving a customer with the other.
Core principle
QRSETU is ONE unified platform, not a collection of separate tools. A merchant doesn't "buy a website builder" or "get a QR generator" — they get one identity, one dataset and one analytics surface, and the platform tells them what to do next.
And the harder half of it, which is the actual bar:
Every feature must answer: "how does this help the user take action and grow their business today?" If the honest answer is "it lets them see or store X", the feature is not finished — it is the substrate a feature would be built on. Displaying data is table stakes, not the deliverable.
The failure mode is not under-building, it is noise. A nudge the merchant learns to ignore does not degrade to neutral; it trains them to ignore every nudge and the mechanism is spent for good. So each interruption has to be earned, in-app surfacing is preferred over a push, and a recommendation the read model cannot support is never made — a fabricated insight is worse than silence because it is unfalsifiable to the user.
One platform, one public surface
The "three pillars" framing is RETIRED (2026-08-08)
This section used to present QRSETU as three products — QRSetu (Interaction), Studio / "My Setu" (Presence, a block-based website builder) and BioLink (Aggregation, link-in-bio) — with a cross-linking diagram and a pillar comparison table.
All three are gone as a product framing. BioLink was retired in favour of the Setu Card on 2026-07-23 (QRS-172) and bio_pages/bio_links were dropped from Dev on 2026-08-08; the Studio website builder is not in R1 and setu_pages/setu_blocks/studio_* are dropped; Digital Menu is legacy/ and R1-excluded. There are no /b/, /s/ or /w/ routes — the only public route is /<slug>.
The pillars were a packaging answer to a question the platform now answers structurally, and much better: industry × archetype × primitives. A merchant is not sold a pillar; the features that apply to their industry are resolved for them.
Why this is the better answer, in one example. A dairy and a boutique are both goods — they both sell a stocked item. They differ because the dairy's composition includes Recurrence (standing orders) and Balance (khata), and the boutique's does not. Under the pillar model that difference had nowhere to live, so it would have become if (businessType === 'dairy') in a screen. Under this model it is one array on one row, and the cost of the platform is O(primitives), not O(industries) — which is what makes the 20th vertical cheap instead of the 20th rewrite.
Full treatment: Industry Scope · ADR-0020 · ADR-0021.
Three user categories, not two audiences
The "two audiences" model is RETIRED (2026-08-08)
This section used to model business users and individuals in generic mode, with a table of "generic business-independent features" marked 🟢 Live — including BioLink, forms, polls and a vCard builder. That table described the retired SPA's feature set, and the framing missed a whole category.
QRSETU serves three fundamentally different user categories, which differ in goals, authentication, onboarding, authorization, feature set, navigation, subscription model and billing — so they differ in schema:
| Category | Owns | Governs their own industry/plan? | |
|---|---|---|---|
| 1 | Business owner (solo SMB) — primary R1 audience | Their Setu Card, catalogue, payments, leads, bookings, analytics | Yes — chosen at onboarding |
| 2 | Enterprise organization | An organization workspace tree, its own admin portal, centralized seat-based billing, employee management | No — the org admin assigns it |
| 3 | Individual consumer | Nothing merchant-side. A completely different dashboard | N/A — no business at all |
Three consequences that must hold in every design:
- The principal is a USER; a workspace is the BUSINESS tenant. 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.
- Anonymous-first for consumers is a hard requirement. A vendor's card must be fully usable with no account. A signup wall in front of a scanned card destroys the platform's entire growth mechanic.
- ⚠ Consumers change what
authenticatedmeans. It stops meaning "merchants, a small semi-trusted population" and starts meaning the logged-in general public — soon the largest population on the platform. So no policy may grant access by role alone.
Full role/onboarding/permission/billing matrix, plus how each type maps to real tables: User Ecosystem.
Target market & positioning
- Who: Indian MSMEs / small service businesses (restaurants, real estate, coaching, trades, creators). Source docs cite a TAM of ~2.5 Cr service MSMEs and a 2–3 year target of ~10 lakh users.
- Design philosophy: QR-native, lightweight, mobile-first, minimal admin overhead, India-first (UPI, vernacular intent).
- Differentiation (vs. the fragmented status quo):
SUPERSEDED 2026-08-18 — the table below is the WRONG COMPETITOR SET
Read Strategy: competitor analysis & market positioning instead, and in particular the differentiation verdict and the competitive landscape.
The four rows below were the platform's entire competitive position until 2026-08-18, and three of the four are the wrong contest. Wix and Squarespace are Western website builders; Linktree is a creator tool; Zomato is an aggregator in a category industry scope explicitly excludes. A Dadar stall vendor, a dairy owner and an independent distributor are choosing between a notebook, WhatsApp, and nothing — and the real competitor set is WhatsApp Business, Google Business Profile, Justdial and ONDC, none of which appeared anywhere in this portal until the strategy section was written. Retained here as the historical record of what was claimed.
| Competitor | Category | How QRSETU differs |
|---|---|---|
| Google My Business | Listing/discovery | Dynamic, instantly-updatable pages + offline→online QR bridge + direct engagement |
| Linktree | Link-in-bio | Rich content/forms/CTAs inside a wider ecosystem, business-centric |
| Wix / Squarespace | Website builders | Simplicity + speed + cost; QR-integrated; not a full CMS |
| Zomato / Swiggy | F&B aggregators | Own the customer relationship + data; no commission; sector-agnostic |
Go-to-market: phased business waves
Reusable service modules (Listings, Appointments, Bookings, Portfolios, Schedules, Reviews, Availability) recombine per business type — the same blocks cover 40+ business types.
- Wave 1 (high-touch, high-volume): Real Estate, Restaurants, Travel, Coaching, Schools.
- Wave 2 (trade & wellness): Electricians, Plumbers, Photography, Yoga, Solar.
- Parked: Gyms, Salons, Event Planners, Tutors, Mechanics, Artists, Musicians, Legal.
See Target End Users & Use Cases for the curated list mapped to live capabilities (with roadmap-gated needs flagged).
Template-first strategy — CORE (decided 2026-07-14)
Ship instant value: business owners pick a pre-built template, fill structured fields (Zod-validated), and publish in < 2 minutes — never touching HTML/CSS.
This is the one strategy on this page that survived the redesign essentially intact, and it is now ADR-0019. What changed is how a template is stored and who authors it:
- A template is a repo-authored, CI-validated JSON manifest over a CLOSED block vocabulary — never markup. That is what makes AI-authored templates safe: Claude Design generates a manifest + palette (JSON data), so there is no rendering logic to review, only data to validate.
- No admin builder UI and no DB-authored content in R1.
setu_card_templatesis a registry seeded from the manifest files, never authored independently of them. - ⚠ The old "248 admin-managed templates (168 QRSetu + 50 Studio + 30 BioLink)" target is retired — it counted templates for two products that no longer exist. R1 ships framework contracts + one manifest-driven template + two palettes; the picker and multi-template land later.
- Switchable at any time, losslessly, forever, enforced by one gated invariant: a manifest block may reference a field, never contain vendor content. Without it, someone eventually adds a "custom headline" prop to a template and from that moment switching silently destroys vendor content.
This is the #1 architecture item — currently greenfield
Template-first is now the agreed core direction, but the templates / template_selections tables are used nowhere in src/ today — the live app is 100% dedicated per-feature UIs (digital-menu, website-builder on setu_blocks, etc.). Adopting template-first means introducing a schema-driven rendering layer (templates table → JSONB field schemas → a renderer) and deciding how it coexists with, or subsumes, the existing per-feature tables. This must be sequenced deliberately before it drives feature architecture.
Monetization (intent)
STALE 2026-08-18 — the live pricing decision is elsewhere, and the ad line should be disowned
What is actually decided and seeded: ONE paid plan — Business, ₹9,999 per festival session plus a 5% commission on online payments (owner decision 2026-08-15 after visiting 12 Ganapati vendors). platform_plans.pro.price_minor and enterprise.price_minor are NULL, and there is no subscription collection path — see subscription payments.
The "non-intrusive ads on public pages" line below should be treated as retired, not merely stale: ADR-0004's resolver fails closed forever, its brand question is still open, and the archived ₹4.75 Cr ad-revenue projection assumed 950,000 free users. Full argument and a costed 12-month model: Revenue model vs the target.
Freemium: a genuinely usable Free tier (all features + non-intrusive ads on public pages) and paid tiers that remove ads and unlock advanced features (custom domains, custom fields, faster data, priority support). Source docs cite ₹499 / ₹999 / ₹4,999 tiers and a blended ad + subscription ARR target.
Representative use cases
Rewritten 2026-08-08 onto the archetype model. Each names the primitives it needs, because that is what decides whether it is configuration or new engineering.
| Merchant | Archetype | Primitives | The loop |
|---|---|---|---|
| Ganapati stall vendor — the R1 launch vertical | goods | Catalogue · Fulfilment | Prints a QR for the stall → customer scans, browses idols with photos and prices, places an order → vendor fulfils. Finite stock matters: one 3-foot idol cannot be sold five times. |
| Dairy | goods | Catalogue · Recurrence · Balance · Party · Location | Standing order "1L daily, skip Sundays, paused 3–7 Aug" → monthly khata → collection points as locations, not workspaces. The Recurrence + Balance pair is exactly what a boutique does not have. |
| Independent electrician | expertise | Catalogue · Party | Enquiry from a scanned card → quote → follow-up reminder. No stock, no slots. |
| Yoga trainer / tutor | time | Schedule · Recurrence · Party · Balance | Bookable slots, a recurring term, a per-student balance. |
| Boutique | goods | Catalogue · Fulfilment | Same archetype as the dairy, deliberately: they differ only by composition. |
| Car dealership — the enterprise case | goods | Catalogue · Party · Asset · Campaign · Location · Resource | Organization → workspace tree (HQ → showrooms → agents) → 39 cards on 30 seats; the customer sits at the showroom so sales and service join by construction; campaigns publish centrally to every agent's card. |
⚠ Corrected 2026-08-08. This list previously read: "Multi-branch coaching center — per-branch Setu pages + one BioLink hub", "Photographer — Studio portfolio site", "Restaurant — dynamic QR menu + BioLink + Studio brand site", "Creator/influencer — BioLink hub". Four of five use cases were built on two retired products. The restaurant example is doubly wrong: cafés and restaurants are explicitly out of scope (industry scope §5) because they are aggregator-fed and will not do the promotional work the growth mechanic depends on.
Vision vs. Current Reality — alignment decisions (resolved 2026-07-14)
The legacy vision docs (mostly Nov 2025) described a product that diverged from
src//supabase/and fromCLAUDE.md. Each item was verified against the codebase and decided with the product owner on 2026-07-14. Status: ✅ resolved · 🏗️ resolved, architecture work implied.
1. ✅ Module scope — 6 modules → 3 pillars + built features; CRM/Finance = roadmap
The vision docs listed 6 modules (adding ClientSetu / CRM and LedgerRadar / Finance). Reality: 3 pillars only. ClientSetuDashboard.jsx is an orphaned, unrouted stub; LedgerRadar has no page or tables; there are no CRM/ledger tables (only engagement_response_contacts for form captures). Meanwhile reminders, business-card, and engagements are built but were missing from the vision.
Decision: Core = the 3 pillars + the built features (digital-menu, website-builder, biolink, qr-generator, business-card, engagements, reminders, profile, settings, dashboard, onboarding). CRM + Finance are roadmap, not core — design the data model to accommodate them later, don't build now. ClientSetuDashboard.jsx → cleanup candidate (remove in the stale-doc/dead-code pass, with confirmation).
2. ✅ Mobile strategy — Capacitor → Expo / React Native
Vision docs said Capacitor + PWA ("99% reuse"); CLAUDE.md says Expo / React Native over a shared DOM-free TS core. Neither is built.
Decision: Expo / React Native is authoritative (matches the shared-core rule already enforced). The Capacitor / PWA / offline-first framing in the legacy docs is stale — flag for cleanup.
3. ✅ Data-sync — "polling-first" → RPC + TanStack Query
Vision docs called tier-based RESTful polling the finalized architecture and used supabase.from() directly. Reality: CLAUDE.md bans from(); reads = RPC via TanStack Query, writes = Edge Functions. The only polling in the whole app is a single refetchInterval: 60000 in one public status banner.
Decision: RPC + TanStack Query stands (see Data Access). Polling survives only as optional per-query staleTime/refetchInterval tuning, not an architecture. The consolidated-analysis from() examples are now anti-patterns — flag for cleanup.
4. 🏗️ Data model — "4-table hybrid / qr_pages" → per-feature tables (+ template layer to come)
Vision docs described a generic 4-table hybrid (business_profiles + profile_items + profile_analytics + profile_revisions), a generic qr_pages config table, and a domains table. Reality: the identity table is profiles (the profile_* tables do exist); the platform uses dedicated per-feature tables (digital_menus, bio_pages/bio_links, setu_pages/setu_blocks, engagement_forms, qr_codes); domain config is business_domains/domain_features/user_domains. No qr_pages, no business_profiles.
Decision: Per-feature tables are canonical; retire the qr_pages/business_profiles framing. But because template-first is now core (§below), a schema-driven template/rendering layer must be reconciled with these per-feature tables — that's live architecture work, not just a doc fix.
5. ✅ Studio / Setu — parallel schemas → setu_* canonical, studio_* is dead
The DB has two parallel website-builder schemas. Verified: the website-builder feature uses setu_pages / setu_blocks (+ increment_setu_view_count) only; studio_websites / studio_pages / studio_blocks_library have ZERO references in src/.
Decision: setu_* is canonical; the studio_* tables are legacy/dead → cleanup candidate (drop via migration after confirming no external consumers). Keep "Studio / My Setu" as the product name, but the schema is setu_*.
6. 🏗️ Template-first — CORE, but greenfield
templates / template_selections tables exist but are used nowhere in src/. Template-first is now the agreed core direction (see the warning box above).
Decision: Treat schema-driven template rendering as the #1 architecture initiative to sequence; until then, per-feature UIs remain the working model. The 248-template count, Handlebars engine, and freemium tier-gating (subscription_tiers/user_subscriptions scaffolding exists) are roadmap targets to design toward, not current capability.
Next steps
- Rewrite this page's upper half to state the aligned vision as fact and drop the DRAFT banner (pending your OK on the wording).
- Sequence the template-first / schema-driven architecture initiative (§4 + §6) — the biggest open design question, feeding the HLD.
- Stale-doc & dead-code cleanup (separate pass, per your ask) — quarantine/annotate the legacy
documentation/00-overview/*claims now known false (polling-firstfrom()examples, Capacitor, CRM/Finance as shipped modules,qr_pages/business_profiles), and remove dead code (src/pages/ClientSetuDashboard.jsx, thestudio_*tables) after confirmation.