Competitive landscape · build reference · v2

Name-card scanners &
personal CRMs — a visual atlas

Twenty-seven tools, read for a build. This opens with the analysis — where the market is, who leads each job, and the practices worth copying — then the full filterable catalogue sits in Appendix A, each tool as a faithful mockup of its layout family (not a screenshot) with a link to its site.

Purpose: reference for building a personal name-card + work-CRM tool Sourced: web, Jun 2026 Discipline: vendor accuracy claims = OPINION until tested

00Orientation — three genres

"Name-card scanner slash work CRM" sits across three categories people routinely conflate. The strongest builds treat them as separable layers.

1 · Capture-first scanners

Paper card → structured contact. OCR & the review screen are everything.

Win condition: parse accuracy + correction speed

2 · Personal CRMs (PRMs)

Keep people warm: history, reminders, "you haven't spoken in 3 months."

Win condition: you actually open it → low-friction capture

3 · Hybrid lead-capture

Scan → enrich → qualify → sync to CRM. Built for sales & events.

Win condition: lead-to-CRM latency (hours not days)

01Overall analysis

The strategic read across all 27 — and what it implies for a custom build.

Capture has been commoditised. Apple Live Text and Google Lens already parse a card for free, on-device, offline. A tool that only scans has no moat — so across the category the value has moved downstream: qualify, dedup, nudge, and sync. Apps that stop at raw capture leave you a list you still have to clean by hand.

The category is littered with corpses. ABBYY killed its cloud sync in 2023; BizConnect stopped shipping. "Best scanner" listicles still recommend both. Active development is itself a selection criterion — and a reminder that a solo-built tool you control sidesteps abandonment risk entirely.

It splits on three axes. Auto-sync vs manual entry (Dex/Clay/Cloze vs Monica/Notion); organised by person vs project vs pipeline (Dex vs Storyflow vs folk); and cloud vs local-first (Clay vs Monica/Dextr). Where you land on each axis is the whole design.

Paper is declining, not dead — and least dead where you work. Digital exchange (QR/NFC) is rising in tech/SaaS, but manufacturing, healthcare, and most of APAC still run on paper. For institutional finance in Singapore, bilingual EN/CJK cards remain routine — so multi-language OCR and on-device handling matter more for you than for a US SaaS user, not less.

The white space (inference). No incumbent combines on-device / local-first privacy + vision-LLM parsing + a Notion-native canonical store + relationship nudges tuned to a work counterparty network. Dextr is closest on local-first but is Apple-only and not Notion-backed; Clay leads enrichment but is cloud and access-hungry; Dex leads nudges but is LinkedIn-bound. That gap is a credible build thesis — and, given a publish-to-demonstrate strategy, the artifact itself has value beyond the tool.

Build vs buy, honestly. For most people: buy — Dex, Clay, or free Wave Connect cover it. Building is justified here by your stack and the demonstrability of the artifact, provided you scope to the gap: lean on free on-device OCR (Apple Vision) plus a small local or sub-cent model for structuring, and spend your effort on the canonical store, the nudge engine, and the work-context layer no one else builds.

Leaders at a glanceRanked on capability & fit — not visual style. Mockups in §02 show layout only; full rationale there.

02Category leaders

The standout for each job, with its closest runner-up. Mockups show each leader's layout family; names link to the tool.

03Best practices — what the leaders do that you should copy

Distilled from how the category leaders actually behave. These are the patterns worth porting into a build.

04Decision matrix

If you were buying rather than building — or choosing a reference to study — start here.

05Build architecture

The decisions that matter most for a custom build on a Notion / MCP / Apple-hardware stack.

On cost — you almost never need a vision LLM

Parsing is two steps, and the cheap split wins. Step one is OCR (image → text); step two is structuring (text → {name, title, company, emails, phones}). Modern phones do step one on-device for free (Apple Vision, Google ML Kit). Step two is then a text task — a few hundred tokens, no image — so it runs on a tiny local model or a sub-cent cloud call. A full vision LLM (sending the image) only earns its keep on hard cards — foil, vertical, dense bilingual — where OCR garbles reading order. Use it as a fallback, not the default.

Parsing — three cost tiers

TierApproachPer cardPrivate / offlineUse when
0 · On-deviceApple Vision / ML Kit / PaddleOCR for OCR → rules or a tiny local text model to structure$0Yes / YesDefault — esp. work contacts
1 · Local VLMQwen3-VL 3–7B, PaddleOCR-VL 0.9B or SmolVLM2 on your Mac/desktop via Ollama / LM Studio / MLX, served over Tailscale$0 (power)Yes / on-LANHard cards; one private engine for all devices
2 · Cheap cloudGemini 3.1 Flash-Lite / Flash, GPT-nano, Claude Haiku — image or text~$0.0002–0.002No / NoFallback, or mobile away from your mesh

The "expensive" worry is mostly a mirage at personal scale. Even Tier 2 with a cheap multimodal model is a fraction of a cent per card — a few hundred cards a year is pennies. Real cost only appears at high volume or if you reach for a frontier vision model (Opus / GPT-5 vision) you don't need. For a private work book, Tier 0/1 is both cheaper and more appropriate.

Local models worth trying (mid-2026)

ModelSize / runs onWhy for cards
PaddleOCR · PaddleOCR-VL0.9B · runs nearly anywhereDedicated doc OCR, strong CJK — fits bilingual Asia cards
Qwen3-VL (or 2.5-VL)3–7B · Mac Mini (MLX/LM Studio) or HomeAMD GPUBest small VLM for documents; ~95 DocVQA, 32-language OCR, reads tilted/low-light
SmolVLM2 / Gemma 32–4B · 4GB-class GPU, iPad-feasibleTiny; fine for structuring + clean-card OCR
Apple Vision + on-device LLMbuilt into iOS / macOSFree OCR; pair with a small local text model to structure — zero marginal cost, fully offline

On-device vs cloud — the central fork

On-device (Vision / ML Kit / local)Cloud (server / hosted LLM)
Latency~100–500ms / card; 50 ≈ 5–25s~1–5s / card; 50 ≈ 50–250s
OfflineWorks — airplane mode, basementsQueues or fails without network
PrivacyData never leaves deviceTemp on vendor infra; GDPR/PIPL exposure
AccuracyStrong on clean cards; weaker on foil/dark/verticalHistorically better field mapping
CostNo per-page computePer-page cost → scan quotas

The asymmetry trap: cloud apps let you capture offline but silently queue the parse. The UI looks fine while cards pile up unsynced. On-device parsing avoids this — surface queue state explicitly if you go hybrid.

Recommended layering

  1. Capture — camera + edge detect; always succeeds locally, never blocked on network.
  2. Parse — on-device first for instant, private feedback; optional cloud/LLM re-parse for hard cards.
  3. Review — card image + editable fields, tap-to-correct. Non-negotiable.
  4. Canonical store — local-first DB synced to one source of truth (a Notion contacts DB fits). Dedup here.
  5. Relationship layer — timeline, keep-in-touch cadence, tags, voice notes, "met where/when," nudges.
  6. Enrichment — job-change / profile fill. Highest privacy cost → opt-in per contact.
  7. Portability — vCard + CSV minimum; direct sync as upgrade. Never trap data.

06Reading the catalogue — seven UI paradigms

Strip the branding away and every tool collapses into one of these layout families. Each card in the appendix uses the matching paradigm.

Genre All Scanners Personal CRM Hybrid DIY Lens Offline-capable On-device parse
Appendix A · full catalogue — 27 tools, full detail