Business Requirements

(Product renamed from working title "NetworkPro" to Dhaga — धागा, "thread" — July 2026. Mentions of NetworkPro below are historical.)

Product: Dhaga — Intelligence in Your Network Version: 0.1 (Draft) Date: 2 July 2026 Owner: Anchit Shrivastava

1. Executive Summary

NetworkPro is an AI-native personal CRM that turns fleeting professional encounters into a living, searchable knowledge graph. Where legacy products (ABBYY BCR Pro, CamCard) stop at "scan a card → save a contact," NetworkPro treats the scan as the ingestion point of a compounding intelligence system: contacts are auto-grouped by context (event, time, place), enriched with public data, connected through voice-note-derived relationships, and made queryable in natural language.

One-line pitch: Your professional memory, augmented.

Business model: Open-core. The client apps and self-hostable core are open source (community trust, zero-cost adoption, contributor leverage); revenue comes from a hosted cloud tier (sync, enrichment, team graph) and a one-time "lifetime" purchase echoing the BCR Pro pricing model that validated this market.

2. Problem Statement

1. Capture is easy; memory is not. Existing card scanners digitize contacts but lose all context: where you met, what you discussed, why it mattered. Six months later the contact is a dead row in an address book.
2. Notes don't compound. Even diligent networkers who take notes can't query across them ("who did I meet in logistics who mentioned an AI budget?").
3. Networks decay silently. Job changes, funding events, and relationship staleness go unnoticed — precisely the moments when outreach is most valuable.
4. Incumbents are stagnant. BCR Pro is functionally identical to its 2015 self; it validated willingness-to-pay (AUD $99.99 one-time) without ever adding intelligence. The category is ripe for an AI-native replacement.

3. Target Users

4. Competitive Landscape (researched July 2026)

The market splits into five camps. Nobody occupies the intersection NetworkPro targets: event-native capture + private knowledge graph + AI intelligence + open source.

4.1 Camp A — Card scanners & digital business cards

Takeaway: this camp has nailed capture UX (badge scanning is now table stakes — we must match it earlier than planned) but treats the contact as the end product. None build a queryable memory on top.

4.2 Camp B — Personal CRMs

Takeaway: subscription fatigue is real in this camp ($10–18/mo for what users perceive as a contacts app), and every one of them is weak at in-person event capture — our wedge.

4.3 Camp C — Team relationship intelligence (the high end)

Takeaway: these prove the team graph (our v2.0) is worth $1.8K–3.6K/user/year to relationship-driven firms. A bottoms-up, capture-first product that grows into a lightweight team graph at 1/10th the price is a classic disruption path.

4.4 Camp D — Capture extensions (sales tooling)

Add to CRM, folkX, Apollo, Seamless.AI — one-click LinkedIn→CRM Chrome extensions with enrichment (20+ data points/contact). All are sales-prospecting tools feeding team CRMs. This validates the browser-extension capture pattern we're adopting, but none feed a personal, private graph — and their scrape-heavy enrichment posture is exactly the privacy stance we differentiate against.

4.5 Camp E — Open source

Takeaway: the open-source niche for an AI-native, mobile-first, professional network tool is empty. Monica's popularity despite its limitations shows the demand for self-hostable relationship software.

4.6 Positioning statement

For professionals who build their careers on in-person and online networking, NetworkPro is the only tool that captures a contact from anywhere — card, badge, QR, LinkedIn page, pasted email — in one action, and turns every note into a private, searchable knowledge graph with proactive intelligence. Unlike digital-card apps it remembers who they are to you; unlike personal CRMs it captures at the moment of meeting; unlike enterprise relationship platforms it is affordable, personal, and open source.

Strategic implications adopted into scope:

1. Badge scanning moves up to v1.1 (Blinq/HiHello/Popl made it table stakes).
2. Browser extension is a first-class capture surface (validated by folkX/Add to CRM adoption) — promoted into v1.1.
3. Lifetime pricing stays (BCR Pro anchor) alongside subscription — an explicit counter to Camp B's subscription fatigue.
4. Privacy/open source is the marketing spearhead against Clay/Mesh and the sales-tooling camp.

5. Product Scope: MVP vs Full Product

5.0 Platform scope

The web app and extension share one TypeScript core (parsing, API client) — the extension is effectively the web quick-add panel in a popup. Both write through the same ingestion API the mobile app uses, so every capture surface feeds the same graph.

5.1 MVP (target: 3–4 months to TestFlight/Play beta)

The MVP must prove one loop end-to-end:

Scan → auto-group by event → voice note → entity extraction → natural-language search → AI follow-up draft

Explicitly out of MVP: team features, enrichment from external sources, change-detection alerts, Android badge/QR formats beyond vCard QR, CRM integrations, Apple Watch.

5.2 Full Product (12–18 month horizon)

5.3 MVP vs Full Product — at a glance

6. How It Will Be Achieved — Feature-by-Feature Mechanics

6.1 Capture (M1)

• OCR is free and on-device. iOS: Apple Vision framework (VNRecognizeTextRequest) — excellent accuracy, zero cost, zero latency, zero privacy exposure. Android: Google ML Kit Text Recognition (also free, on-device).
• OCR yields raw text lines + bounding boxes. A small LLM call (or on-device model) converts raw OCR text → structured contact JSON (name/title/company/email/phone/address), handling layout ambiguity that regex can't ("is this line a company or a title?").
• Fallback for degraded/multilingual cards: server-side pass with a vision-capable model (send the image, get structured JSON directly). This is the premium path, used only when on-device confidence is low.

6.2 Auto-grouping (M2)

Pure client-side logic — no AI needed for v0:

• Each scan records timestamp + coarse geohash (with user permission).
• Scans within a rolling window (same geohash-6, gaps under 4h) cluster into a Event.
• First scan in a new cluster prompts once: "Name this event?" (pre-filled from calendar if an all-day event matches).
• Later (v1.2): batch LLM pass suggests merging/splitting events and infers "these 3 people were probably in the same conversation" from sub-minute scan proximity.

6.3 Notes → Knowledge Graph (M3–M5)

• Transcription: whisper.cpp (or Apple's on-device speech APIs on iOS 17+) — free, private, offline.
• Extraction: one structured-output LLM call per note. Schema (enforced via the API's output_config.format JSON schema, so output is guaranteed parseable):

{
  "facts": [{"type": "role|intent|personal|preference", "text": "...", "confidence": 0.9}],
  "relationships": [{"subject": "contact", "predicate": "works_at|used_to_work_at|knows|reports_to|invests_in|competitor_of", "object": "Acme Corp", "object_type": "company|person"}],
  "follow_ups": [{"action": "...", "due_hint": "when their fiscal year starts"}],
  "tags": ["fintech", "decision-maker"]
}

• Graph storage: nodes (person, company, event, tag) and edges (typed, timestamped, source-linked to the originating note) in plain relational tables. A property graph in SQLite/Postgres is entirely sufficient at this scale — a dedicated graph DB (Neo4j) is deliberate over-engineering for under 100k nodes per user. Every fact keeps a pointer to its source note for auditability ("why does the app think Sarah is leaving Stripe?").

6.4 Natural-language search (M6)

Hybrid retrieval, three stages:

1. Query understanding: small LLM call converts the query into structured filters (event=GITEX, sector≈fintech) + a semantic residual.
2. Candidate retrieval: structured filters via SQL + semantic match via vector embeddings over notes/facts (sqlite-vec on device; pgvector in cloud). Embeddings from an open model (e.g. bge-small / nomic-embed-text) — runnable on-device or on a $5 VPS.
3. Rerank + answer: LLM reranks top-20 candidates and composes the answer with citations to the underlying notes.

Stage 1 and 3 are skippable for simple queries (keyword fallback), keeping most searches free and instant.

6.5 Follow-up drafts (M7)

Single LLM call: contact + event context + extracted facts + user's writing-style sample → draft. Prompt-cached system prompt makes marginal cost negligible (see §9).

6.6 Full-product intelligence (v1.1+)

• Enrichment: user-triggered web search/fetch for the contact's public footprint (company news, funding, role verification) → summarized into graph facts. Runs through the LLM's server-side web search tooling or a search API; always attributed, always deletable.
• Change detection: nightly Batch API job (50% cost discount, latency-insensitive) re-checks key contacts' public signals; diffs become alerts ("Marcus is now VP at …").
• Pre-meeting briefs: calendar webhook → assemble contact dossier from graph → one LLM call → push notification 30 min before the meeting.
• Warm paths: pure graph traversal (BFS over works_at/used_to_work_at/knows edges) — no AI cost.

6.7 Source legality — the Mesh-style auto-sync we can and can't do (researched 2026-07)

Mesh/Clay-class competitors claim continuous auto-recording from LinkedIn and Twitter. That runs on user-session piggybacking or scraping: LinkedIn's API is partner-gated, closed to CRM/enrichment tools (the Connections API died in 2015; Proxycurl was shut down by LinkedIn legal in 2025), and X's API has no free read tier (pay-per-use $0.005/post read, Enterprise ~$42K/mo) — uneconomical at our price point. Our channels, all user-initiated or opt-in:

Hard lines: no scraping, no session piggybacking, no bulk lookup of people who never consented, no SMS/call-log ingestion (blocked by iOS entirely and by Play Store policy anyway). This is the privacy moat stated as engineering policy — the marketing claim is "one click, one file, nothing scraped behind your back," not "automatic."

7. Technical Architecture

7.1 Principles

1. Local-first. The phone is the source of truth. Everything works offline; cloud is sync + heavy compute, not a dependency.
2. On-device wherever a free primitive exists (OCR, transcription, embeddings). Cloud LLM only where it adds unique value (extraction, search reasoning, drafting).
3. Tiered inference. Cheapest capable model per task; batch wherever latency doesn't matter; cache everything cacheable.
4. Boring storage. Relational tables + vector column. No exotic infra until the graph demands it.

7.2 System diagram

┌──────────── Mobile App (React Native + Expo, iOS + Android) ────────────┐
│  Camera → Vision/ML Kit OCR → contact parser                           │
│  Mic → whisper.cpp transcription                                       │
│  SQLite (source of truth): contacts/events/notes/facts/edges/vectors │
│  sqlite-vec for on-device semantic search                              │
│  Sync engine (field-level LWW) ────────────────────┐                    │
└─────────────────────────────────────────────────── │ ──────────────────┘
                                                     │ E2E-encrypted sync
┌───────── Web App + Browser Extension (shared TS core) ─┐               │
│  Quick-add: paste email sig / article / LinkedIn URL   │               │
│  Extension popup = same quick-add panel + page context │──────────────▶│
│  Full graph browsing & NL search on desktop            │  ingestion API│
└─────────────────────────────────────────────────────────┘              ▼
┌──────────────── Cloud (optional, hosted or self-hosted) ────────────────┐
│  API: Next.js (Vercel) or Node/Fastify — auth, sync, ingestion, billing│
│  Postgres + pgvector (Supabase/Neon/self-hosted): graph + team graph   │
│  Job queue: nightly Batch-API enrichment/change detection, digests     │
│  LLM gateway: routes tasks → model tier, BYO-key support, metering     │
└──────────────────────────────────────────────────────────────────────────┘

Note on web/extension capture: these surfaces have no on-device OCR/transcription needs — their inputs are already text (pasted emails, page DOM, URLs). Ingestion is one structured-extraction LLM call against the same schema the mobile parser uses, so all capture surfaces converge on identical graph writes. The extension reads only the active tab on explicit user click (no background scraping — both a privacy stance and a Chrome Web Store review necessity).

7.3 Stack choices (opinionated)

7.4 Data model (core tables)

contacts(id, name, title, company_id, emails[], phones[], source, created_at, ...)
companies(id, name, domain, sector, enrichment_json)
events(id, name, started_at, ended_at, geohash, calendar_event_id)
event_contacts(event_id, contact_id, scanned_at)
notes(id, contact_id, kind: voice|text, transcript, audio_path, created_at)
facts(id, contact_id, type, text, confidence, source_note_id, created_at, deleted_at)
edges(id, src_type, src_id, predicate, dst_type, dst_id, source_note_id, created_at)
embeddings(owner_type, owner_id, vector)          -- notes + facts + contact summaries
follow_ups(id, contact_id, action, due_at, status)

The graph is edges; the audit trail is source_note_id on facts/edges. Deleting a note cascades tombstones to derived facts — critical for trust and GDPR.

7.5 Privacy & compliance (non-functional requirements)

• On-device processing by default; cloud calls are opt-in and per-feature.
• E2E-encrypted sync (user-held key); the hosted service cannot read graph contents.
• Enrichment is user-triggered per contact, not automatic mass-lookup (GDPR legitimate-interest posture; contacts are data subjects who never consented).
• One-tap "forget this person" — cascades contact, notes, facts, edges, embeddings, backups.
• Data export: full SQLite file + CSV/vCard/JSON at any time. No lock-in is a feature and the open-source promise.

7.6 Web performance (non-functional requirements)

• Fonts and any decorative/non-critical animation ship self-hosted (next/font/local/next/font/google) and stay off the critical render path (e.g. lazy client-only components via next/dynamic({ ssr: false })) — first paint never blocks on an external font or animation download.
• Authenticated /app/* navigation (nav switches, contact/event detail) must not re-run the full set of Postgres queries on every click. Add a caching layer (e.g. unstable_cache/revalidateTag, or React cache()) scoped per-user and invalidated on mutation — never a raw TTL alone, since these routes are RLS-scoped per-tenant data and a stale/leaked cache entry is a privacy bug, not just a UX one.

8. Open-Source & Sustainability Strategy

8.1 Model: Open-core (the Cal.com / Twenty / Supabase playbook)

Implementation status (2026-07): this split is built, not just planned. Real accounts, capture, notes, graph, search, and export are AGPL core and run fully self-hosted with zero packages/ee dependency (see Self-hosting). Multi-tenancy (Postgres RLS), the early-access gate, the admin panel, and Stripe billing live in packages/ee, gated behind a single DHAGA_HOSTED_MODE flag that self-hosted instances simply never set. Team graph/SSO (§5.2 v2.0) will land in the same module once built.

Why open source helps rather than hurts here:

1. Trust is the product. A private-network app asking for your contacts, location, and voice notes needs verifiable privacy claims. "Read the code, run it yourself" is the strongest possible answer.
2. Capture edge-cases are a long tail (card layouts, languages, badge formats). Community PRs handle the tail no small team can.
3. Self-hosters are marketing, not lost revenue. The people who run docker compose up were never going to pay; their GitHub stars bring the people who will.

8.2 Managing LLM cost — the four-layer defense

LLMs are the main marginal cost. Verified current pricing (Anthropic, mid-2026): Haiku 4.5 at $1 / $5 per MTok (in/out), Sonnet 5 at $3/$15, Batch API −50%, prompt-cache reads at ~0.1× input price.

8.3 Unit economics (order-of-magnitude)

Per-card pipeline (OCR parse ≈ 800 in / 200 out tokens on Haiku): ≈ $0.002. Voice-note extraction (≈ 1,500 in / 300 out): ≈ $0.003. NL search with cached system prompt: ≈ $0.005 on Sonnet. A heavy user — 100 cards + 100 notes + 200 searches + nightly digests per month — costs ≈ $1.50–2.50/month in inference. At a $8–10/month Pro price (or $99 lifetime ≈ amortized $2.75/mo over 3 years), gross margin stays >70% even before caching/batch savings. The free tier caps cloud AI actions (e.g. 25/month) and runs everything else on-device — free users cost ~$0.

8.4 Revenue streams

1. Pro (individual): hosted sync + unlimited AI actions + enrichment + alerts. Monthly, yearly, and a lifetime tier — deliberately echoing BCR Pro's proven one-time-purchase psychology.
2. Teams: per-seat, shared graph, SSO, admin. The defensible, expanding revenue line.
3. Self-host support (later): paid support/SLA for companies running the AGPL stack internally.

8.5 Community flywheel

• Public roadmap + good-first-issues on capture parsers and language support.
• Prompt/eval library in the open: contributors improve extraction quality measurably (eval suite gates PRs).
• Plugin interface for capture sources (badge formats, email parsers) and export targets (CRMs) — the integrations surface area becomes community-maintained.

9. Delivery Plan & Milestones

Success metrics (MVP beta):

• ≥70% of scans require zero manual field correction
• ≥40% of contacts get a voice/text note attached (the graph's fuel)
• ≥30% of weekly-active users run at least one NL search
• Follow-up draft used (copied/sent) for ≥25% of new contacts

10. Risks & Mitigations

11. Open Questions

1. Lifetime-tier pricing: $79 vs $99 vs $129? Needs willingness-to-pay testing against BCR Pro's AUD $99.99 anchor and Clay/Mesh's ~$10/mo.
2. Sync build-vs-adopt: PowerSync/ElectricSQL licensing fit with AGPL?
3. Enrichment data sources: which are ToS-safe? Resolved 2026-07 — see §6.7. LinkedIn API is partner-gated and closed to CRMs; X API reads are pay-per-use and uneconomical. Channels: user-triggered web search, LinkedIn Connections CSV import + re-import diff, opt-in news watchlist, extension DOM capture. Remaining sub-question: is this enrichment quality enough vs Popl's claimed 90%?
4. Browser extension and LinkedIn: confirm legal posture. Resolved 2026-07 — see §6.7. User-initiated, single-profile DOM read of a page the user is viewing (folkX/Add to CRM pattern) is the posture; shipped in the extension. No automation, no bulk collection.
5. Brand/name: "NetworkPro" is a working title; trademark search needed.

Appendix A — pricing sources: Anthropic API pricing verified 2026-07 (Haiku 4.5 $1/$5 per MTok; Sonnet 5 $3/$15 with intro $2/$10 through Aug 2026; Batch API −50%; prompt-cache reads ~0.1× input, writes 1.25×).