Building a Community Discovery Platform for Kannadigas in the United States.
From a fragmented discovery problem to a scalable community platform — a product-first case study covering problem framing, PRDs, UX decisions, trust primitives, instrumentation plan, and roadmap. Every non-shipped claim is labelled honestly.
Karnataka Connect is a community discovery platform for the Karnataka diaspora in the United States. It brings organizations, events, learning programs, and places from dozens of scattered sources into one structured product — with automated ingestion from each organization's own website and lightweight admin moderation to keep quality high.
Community information exists. Discovery is broken. A Kannadiga trying to find their local sangha, an upcoming Sankranti event, or a Kannada school for their kid has to search across org websites, WhatsApp groups, Facebook pages, Instagram, and email newsletters — and still misses things.
I frame the problem, define the product, decide the trade-offs, design the UX, and ship the code — a one-person operation that documents every decision with honest state labels. Nothing is inflated.
Karnataka-related content is published continuously — but across dozens of channels that don't talk to each other:
Informed by my lived diaspora experience + informal conversations with community members. No structured research yet.
The problem isn't a content shortage. Orgs are active, events are happening. The problem is discovery — not publishing.
All persona claims are Hypothesis — informed by lived experience and informal conversations, not by a formal research program.
Kannadiga living in the US for years; member of at least one sangha.
Behavior: Checks WhatsApp regularly; misses events from unaffiliated orgs.
Needs: Aggregated cross-org view; notifications about upcoming things.
Recently moved to the US for work or study; searching for community roots.
Behavior: Google → confusing results → asks in Facebook expat groups.
Needs: Introductory map of local Kannadiga community, org contacts, upcoming events.
Moving between US cities or visiting for work.
Behavior: Doesn't know who to ask in a new city.
Needs: City-scoped discovery.
Runs events for a sangha.
Behavior: Posts to org WhatsApp + Facebook; wonders why turnout isn't larger.
Needs: Distribution reach beyond the core audience, with attribution back to the org.
Wants children exposed to Kannada language and culture.
Behavior: Asks in parent WhatsApp groups; unclear on Kannada school options in area.
Needs: Structured Kannada learning program discovery.
What's validated
What isn't validated
Explicit gap: formal validation is a Phase 2 priority.
The product isn't a directory. It's a compression of a 30-minute discovery task into 3 minutes.
Before Karnataka Connect
20–60 minutes · low success rate
With Karnataka Connect
1–3 minutes · structured relevance
| Stage | Customer goal | Friction (before) | Product opportunity |
|---|---|---|---|
| Trigger | Find something specific | Doesn't know where to look | Single known destination |
| Search | Locate relevant info | Fragmented across channels | Structured directory |
| Discover | Find things I didn't know existed | No cross-org visibility | Near-Me and Events surfaces |
| Filter | Narrow to what fits | Manual across tabs | City filter, category filter |
| Evaluate | Decide if it's worth attending | Missing details on some orgs | Structured event / org detail |
| Connect | Attend / contact / sign up | Contact info scattered | External links back to source |
Make it easy for every Kannadiga in the United States to discover, connect with, and participate in their community.
Organize around user intent (what's near me, what's happening soon), not around publishing hierarchy.
We ingest and link back. We don't try to own the content.
Phone-in-hand product, not a desktop database.
Feels for this community — not a generic city guide skinned in red.
Coming Soon items are labelled Coming Soon; MVP scope is explicit.
Long-term health depends on community members submitting and correcting information.
Framework: Customer value × frequency of need × implementation feasibility. Every item is labelled with its actual status.
Ship the core discovery loop and moderation flow first.
In or partially in; a few still need instrumentation or ops work.
Live: seeded · Proposed: source-connected
via /submit → moderation queue
via /submit → moderation queue
Phase 3+ scope. Deliberately not shipped in MVP.
Prioritization examples
A representative PRD — enough for an engineer to implement with minimal clarification. Every non-shipped section carries an explicit status.
Problem
Diaspora members want to know what Karnataka events are happening near them without visiting multiple org sites.
User
Diaspora member (established or new arrival) checking their phone for what's upcoming.
Goal
Give the user a scannable list of upcoming events near them, in ≤2 taps from landing.
User story
As a community member, I want to see upcoming Karnataka events happening near me, so that I can decide what to attend without searching multiple sites.
Functional requirements
Non-functional
Edge cases
Acceptance criteria
Analytics events (Proposed — not instrumented)
As a community member, I want to discover Kannada organizations near me, so I can connect with relevant community groups.
Accept
Edge cases
As a member, I want to see upcoming events, so I can attend.
Accept
Edge cases
As a someone new to a city, I want to switch context to that city, so I see relevant community.
Accept
As a parent, I want to find Kannada learning programs, so my kids stay connected to the language.
Accept
As a organizer, I want to submit an event, so more people attend.
Accept
Edge cases
As a community member, I want to submit an org that isn't listed, so it becomes discoverable.
Accept
As a admin, I want to review, approve or reject pending items, so quality stays high.
Accept
As a new visitor, I want to understand what Karnataka Connect is and how to use it, so I can trust it.
Accept
Five decisions that shaped the product. Not screenshots — reasoning.
Problem
What does a diaspora member want to see first?
Options considered
Decision · Why
B — upcoming events carousel
Events are time-sensitive; orgs are stable and can be discovered contextually. Users checking Karnataka Connect are more often asking “what's happening” than “what exists”.
Problem
Where does this product actually get used?
Options considered
Decision · Why
B — mobile-first
Community members check community info on their phones. Native-feel bottom tabs with safe-area padding; desktop is the secondary surface.
Problem
Should the UI look like a generic city guide or feel Karnataka-specific?
Options considered
Decision · Why
B
Visual belonging matters. This is not a utility app; it's the community's front door.
Problem
How do community members submit new orgs / events?
Options considered
Decision · Why
C
(A) and (B) require admin re-entry — friction, human error, dropped submissions. (C) means admin approves in one click and every future improvement (Turnstile, dedupe, verify, org claim) plugs in cleanly.
Problem
Places (restaurants, temples) exist in seed data but aren't source-connected.
Options considered
Decision · Why
C
Product should be honest about its state. A fake “Live” undermines trust.
| Case | Product behavior |
|---|---|
| No search results | Fallback: “Nothing matches — try broader terms or nearby cities” (Proposed) |
| Duplicate organizations | Detected at moderation; admin merges (Proposed detection; manual today) |
| Outdated information | last_updated_at displayed (Proposed) + community “report inaccurate” flow (partial today) |
| Organization closes | Admin marks archived; hidden via RLS (Proposed) |
| Event cancelled | Admin removes; event page shows tombstone (Proposed) |
| Event date changes | Ingestion re-syncs from source; admin re-approves (Live for iCal/RSS; Proposed for manual) |
| Missing location | Card shows city-only fallback |
| Missing website | Org card shows social handle (Proposed) |
| Incorrect community info | “Report inaccurate” → admin (partial via event_reports table) |
| Similar-named orgs | Category + city distinguish; UI shows category badge |
| Incomplete submission | Server validation rejects; friendly error (Live) |
| Spam submissions | Honeypot + server validation (Live); Turnstile / reCAPTCHA (Proposed) |
| Unverified organizations | All new orgs start unverified; verification badge shown once admin verifies (Proposed) |
A community directory people don't trust becomes worse than no directory — misinformation spreads. Every product decision maps to a trust primitive.
| Primitive | Purpose | Status |
|---|---|---|
| Source URL | Every event links back to origin | Live |
| Source type | User sees where data came from (iCal / RSS / scrape / manual) | Live |
| Moderation status | Approved-only public via RLS | Live |
| Ingestion runs log | Audit trail of every source run | Live |
| Report inaccurate | Community can flag bad data | Partial |
| Last updated | Freshness signal per record | Proposed |
| Verified badge | Admin marks orgs verified after direct outreach | Proposed |
| Duplicate detection | Auto-flag near-duplicates for merge | Proposed |
| Confidence score | Ingestion assigns confidence based on source quality | Proposed |
| Data owner | Each org can claim admin control via org_admins | Live |
Data model (Live)
organizations, events, sources, ingestion_runs, event_reports, org_admins, learning_programs.
I don't turn PRDs into implementation tutorials. I make trade-offs engineers can defend.
| Layer | Choice | Why |
|---|---|---|
| Framework | Next.js 16 (App Router) | Server components + revalidation for cacheable public reads; server actions for form submissions. |
| Language | TypeScript | Type safety at every layer; prevents runtime schema drift. |
| Database | Supabase (Postgres + RLS) | Structured directory data + auth + RLS enforces approved-only reads without app-layer checks. |
| Hosting | Vercel | Cron for daily ingestion; edge functions; preview per PR. |
| Ingestion | iCal / RSS / Cheerio | Tiered because orgs publish differently; each parser scoped to one kind. |
Why relational data, not a document store?
Events belong to orgs; orgs have admins; ingestion runs belong to sources. Postgres FKs enforce integrity; RLS scopes visibility. Document store would push these into app code.
Why separate organizations from events?
Same event might be co-hosted by multiple orgs (future). Orgs have their own lifecycle independent of events.
Why RLS instead of API-layer filtering?
The wrong data can never be returned even if a bug slips into the app.
What happens when data changes?
Ingestion runs upsert on (org_id, external_id). updated_at triggers keep the audit trail.
How should APIs support future mobile?
Typed row shapes → the next iteration can expose a small typed layer for a React Native client without rebuilding the backend. Schema is the contract.
Current use of AI: AI-assisted development (LLM-assisted scaffolding, ingestion parsers, iteration). Not in-product yet.
ProposedProblem
“Show me temples near San Jose for Sankranti weekend” — beyond keyword.
AI opportunity
LLM query understanding + structured retrieval.
User value
Faster discovery for complex intent.
Risk
Wrong results erode trust.
Human oversight
Ranked results alongside deterministic search, not replacing it.
Success metric
Search satisfaction rate (Proposed)
Problem
Manual category assignment doesn't scale.
AI opportunity
LLM classifies from title + description.
User value
Consistent categorization.
Risk
Miscategorization.
Human oversight
Admin sees suggested category, approves.
Success metric
% ingested events with confident category (Proposed)
Problem
Multiple orgs may submit the same event.
AI opportunity
Embedding similarity + LLM name-match.
User value
Admin doesn't approve duplicates.
Risk
False positives merge distinct events.
Human oversight
Confidence threshold; human confirms merges.
Success metric
Duplicate rate ≤ 2% (Proposed)
Problem
Sparse submissions.
AI opportunity
LLM extracts details from linked website.
User value
Richer pages faster.
Risk
Hallucinated info.
Human oversight
Extracted content shown as suggested, admin edits.
Success metric
Time-to-publish per submission (Proposed)
Problem
Everyone sees the same rail.
AI opportunity
Behavior-informed ranking.
User value
Higher engagement.
Risk
Filter bubble.
Human oversight
Explain-why on recommendations; user can opt out.
Success metric
CTR lift vs baseline (Proposed)
Problem
“What's a good sangha to join in the Bay Area?”
AI opportunity
RAG over structured directory.
User value
Onboarding for new arrivals.
Risk
Confident wrong answers.
Human oversight
Cite sources on every answer; disclaimer.
Success metric
Task completion rate (Proposed)
Principles
Deterministic first, AI second · transparent sources · human-in-the- loop before public · measurable — every AI feature has a success metric.
North Star
ProposedWeekly Discovery Actions
Count of user sessions that resulted in a meaningful discovery action — event view + external click, org view + contact click, or submission. Captures actual value delivered (successful discovery), not vanity (visits). Grows only when the product is actually helping people connect.
| Layer | Metric |
|---|---|
| Acquisition | Weekly visitors · referral source mix · search traffic share |
| Activation | % first-time visitors who reach an event or org detail |
| Engagement | Sessions/user/week · detail views/session · city filter usage rate |
| Contribution | Weekly submissions (org + event) · approval rate · time-to-approval |
| Quality | Duplicate rate · search zero-result rate · % records with source_url · report-inaccurate rate |
| Outcome | External click-through rate · event RSVP CTR · org contact CTR |
| Trust | Days-since-last-updated distribution · % orgs with admin claimed · % orgs verified |
Instrumentation plan
Vercel Analytics for baseline visits + referrers. Custom event stream (Vercel or Plausible or self-hosted) for the events named in each PRD. Next
No experiments have been run — instrumentation isn't live yet. These are the first three I'd stand up once metrics land.
Hypothesis: Landing on upcoming events (current) drives higher engagement than landing on a city picker.
Variant A
Home leads with events near default city
Variant B
Home leads with a large city picker; events after selection
Metric % sessions that view an event detail within 60s (primary); city changes/session (secondary)
Hypothesis: Placing the “Submit an org/event” CTA in the About footer generates higher submission volume than only surface-card CTAs.
Variant A
Both entry points (current)
Variant B
Footer CTA only
Metric Weekly submission volume; conversion rate by entry point
Hypothesis: Users engage more with orgs that show a “verified” badge.
Variant A
No badge (current)
Variant B
Verified badge on verified orgs
Metric CTR to org detail; qualitative trust perception
Lifecycle
PM responsibility per stage
Observation, informal interviews, journey mapping
Problem statement, user story, acceptance criteria, analytics events
Empty states, error states, mobile-first review
Data model + edge case questions answered
Gate keeper
Unblock; answer product questions
Product acceptance
Product acceptance across devices
Preview + link to stakeholders
Approve merge
Watch for regressions
Read submissions, reports
Prioritize next
Solo build: every role is mine. Framework doesn't change when a team joins — it distributes.
A ticket enters development only when:
Done means:
A representative decision from this actual project — not a hypothetical.
| Option | Cost | UX | Admin friction | Extensibility |
|---|---|---|---|---|
| A — Mailto link | Zero | Feels dated | High (retype from email) | Low |
| B — Form → email | Small | Modern form | Medium | Low |
| C — Form → DB → moderation | Higher | Modern | Zero re-entry | High |
Decision · C
Option A was the honest MVP shortcut for a day. Every subsequent capability (spam control, dedup, verification, org claim, ownership transfer) requires structured data. Front-loading C's cost saves the hidden cost of migrations later, and gives admins a one-click flow they actually enjoy.
What I gave up: a few extra hours to build the form + server actions + admin OrgRow. Bet: the platform's ability to grow depends on frictionless contribution — worth the upfront cost.
Naming the problem is 80% of the work. “Community discovery is fragmented” wasn't obvious until said out loud. Once said, every product decision fell out of it.
A directory is not a product; a discovery experience is. The DB looks the same, but the shape of the UI, ranking, mobile-first tab bar, and city-scoped Home changed because we're building discovery.
Honest labels beat inflated claims. “Places: Seeded” tells the truth. “Places: Live” would be more marketable and less trustworthy.
Direct DB submissions were the right hard decision. Building the mailto version would have shipped in an hour and cost weeks of admin overhead. The fastest shortcut isn't always the right one.
Data quality is UX. Every trust primitive (source URL, moderation, verified badge) is a UX pillar, not a backend concern.
AI belongs where it earns its place. Nothing in the current product uses in-product AI. Instead, six specific opportunities each mapped with user value + risk + human oversight.
Community submissions are the growth engine. No amount of scraping keeps a directory current; the community has to feel comfortable submitting. That's why the form matters more than the ingestion.