Appearance
Product Vision
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
Empower anyone — small businesses and individuals — to build a complete, dynamic digital presence and get everyday digital tasks done through one unified platform. For businesses: QRSetu for instant service discovery and interaction, Studio for a professional website, and BioLink for social-media link aggregation. For individuals: a set of generic, business-independent utilities (QR codes, digital card, link-in-bio, forms, reminders, and more) usable without ever creating a business profile.
Mission
Simplify digital adoption for small-business owners and entrepreneurs with an intuitive, lightweight, affordable toolkit — digitize their services, engage customers via QR codes, and run operations with minimal admin overhead.
Core principle
QRSETU is ONE unified platform, not a collection of separate tools. A business owner doesn't "buy a website builder" or "get a QR generator" — they get a digital operating system where every component shares one identity, one dataset, and one analytics surface.
This is the stable core the whole team agrees on. Everything below serves it.
The three pillars
| Pillar | Purpose | Access | Key value |
|---|---|---|---|
| QRSetu (Interaction) | Operational core for service delivery + customer interaction | QR scan | Makes physical services digital instantly |
| Studio / My Setu (Presence) | Lightweight no-code website | Website URL | A credible "home base" + SEO |
| BioLink (Aggregation) | Central landing page for social/marketing traffic | Direct link | Captures high-intent social audiences |
Two audiences: businesses and individuals
QRSETU serves two overlapping audiences on the same platform and shared backend:
- Business users (primary): the three pillars + business-scoped features (digital menu, business website, etc.), tied to a business profile and business type.
- Individuals (generic): students, researchers, freelancers, job seekers, creators, and anyone with everyday personal-productivity needs — who use business-independent utilities without creating or associating a business. Generic features are also available to business users.
Generic (business-independent) features
A feature is generic when it delivers value with no dependency on a business category or profile. Several are already built (today gated behind business onboarding); others are roadmap.
| Generic feature | Maps to | Status | Example individual need |
|---|---|---|---|
| QR code generator | qr-generator | 🟢 Live | Share a link/text/Wi-Fi as a QR |
| BioLink | biolink | 🟢 Live | Personal link-in-bio (creator, job seeker) |
| Digital card (vCard) | business-card | 🟢 Live | Personal contact / mini-résumé card |
| Forms & polls | engagements | 🟢 Live | Google-Forms-style surveys (student/researcher) |
| Reminders | reminders | 🟢 Live | Personal task/productivity reminders |
| Invoicing | — | 🟡 Roadmap | Freelancer invoices |
| Document / file sharing | — | 🟡 Roadmap | Share a file/résumé |
| QR-based file sharing | — (extends qr-generator) | 🟡 Roadmap | Hand off a file via a scannable QR |
Architectural implication — onboarding is business-first today
Onboarding currently requires a business domain/brand (52 "domain" / 15 "business_domain" / 17 "brand_name" references vs. 1 "personal" in onboarding). To serve individuals, we need a "personal / skip business" onboarding path and to decouple the generic features from business_profile so a user can sign up and immediately use QR / BioLink / card / forms / reminders without a business. This is a concrete design item feeding the HLD — the generic features largely exist; the gating is the work.
See Target End Users & Use Cases for both audiences mapped to live capabilities.
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):
| 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. Custom fields arrive later as a Pro-tier feature flag over the same JSONB storage (no migration). Source docs target 248 admin-managed templates (168 QRSetu + 50 Studio + 30 BioLink).
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)
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
- Independent electrician — vCard QR + service-menu Setu page + UPI payment QR; digital presence, zero website overhead.
- Multi-branch coaching center — per-branch Setu pages + one BioLink hub aggregating them.
- Photographer — Studio portfolio site + booking form + QR on business cards.
- Restaurant — dynamic QR menu + feedback QR + BioLink to ordering/social + Studio brand site.
- Creator/influencer — BioLink hub for affiliate links, content, and inquiry forms.
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.