68 projects evaluated for reuse in the SupplyShore procurement operating system.
Star counts, licenses, and last-update dates are snapshots fetched from the GitHub API on 2026-08-07 and should be re-verified at integration time.
Raw data: per-repo GitHub API snapshots live in
data/gh/(75 files), and a machine-readable aggregated table is incatalog.md.
Legend — Difficulty: 🟢 Low (install & use) · 🟡 Medium (some dev) · 🔴 High (substantial engineering).
Legend — Recommendation: ✅ Use · 👁 Watch/evaluate · ⚪ Niche/optional · ✖ Avoid for now.
Purpose: Open-source CRM (self-hosted). SPA frontend (Backbone), PHP REST API, Entity Manager.
Why useful: Current CRM; best-in-class no-code custom entities for a procurement relationship layer; every entity auto-exposes REST for n8n.
Difficulty: 🟢 · Recommendation: ✅ Core (in production)
Purpose: Modern open CRM, "open alternative to Salesforce, designed for AI." Postgres + GraphQL/REST.
Why useful: Strong long-term candidate; AI-native data model. Watch for Phase-C migration.
Difficulty: 🟡 · Recommendation: 👁 Watch (re-evaluate at platform phase)
Purpose: Full open-source ERP (CRM, purchase, inventory, accounting).
Why useful: Best "next step up" if we outgrow EspoCRM+Sales Pack into orders/inventory/accounting. Native RFQ/Purchase modules.
Difficulty: 🟡 · Recommendation: 👁 Plan B (documented in 06-decisions/adr)
Purpose: Open-source business apps (CRM, sales, purchase, inventory, accounting).
Why useful: Powerful all-in-one; but Community lacks Studio (custom UI needs code); heavier footprint. Overkill for current stage.
Difficulty: 🟡 · Recommendation: ⚪ Niche (revisit only if full ERP needed)
Purpose: Open-source CRM (SugarCRM fork), mature, huge feature set.
Why useful: Viable alternative but heavier/legacy UI; weaker modern API story than EspoCRM/Twenty.
Difficulty: 🟡 · Recommendation: ✖ (EspoCRM is superior for our needs)
Purpose: Reliable Node.js web-scraping & browser-automation library (headless browsers, anti-blocking).
Why useful: Core scraping engine for supplier/marketplace/discovery scraping; proxy & autoscaling support.
Difficulty: 🟡 · Recommendation: ✅ Use (Node)
Purpose: Same crawling library in Python (Playwright-based).
Why useful: Native fit with our FastAPI/Python + AI stack for scraping pipelines.
Difficulty: 🟡 · Recommendation: ✅ Use (Python) — preferred if backend is Python
Purpose: Browser automation/testing framework (Chromium, Firefox, WebKit).
Why useful: Foundation for any JS-rendered scraping; robust waits, contexts.
Difficulty: 🟡 · Recommendation: ✅ Use (underlies Crawlee)
Purpose: Chrome DevTools-driven browser automation.
Why useful: Playwright is generally preferred today; Puppeteer is simpler for Chrome-only tasks.
Difficulty: 🟡 · Recommendation: ⚪ Niche (Playwright preferred)
Purpose: Fast, high-level Python web crawling & scraping framework.
Why useful: Great for structured, large-scale crawls (directories, marketplaces); mature pipelines.
Difficulty: 🟡 · Recommendation: 👁 Evaluate for big scheduled crawls (Crawlee for browser-heavy)
Purpose: Deploy headless browsers in Docker/cloud (hosted or bring-your-own).
Why useful: Centralize browser infrastructure for scraping at scale; free for non-commercial.
Difficulty: 🟡 · Recommendation: 👁 Evaluate when scraping scales (else Crawlee handles it)
Purpose: Next-gen crawling/spidering framework (fast, headless/headful).
Why useful: Very fast passive crawler for site discovery/research.
Difficulty: 🟡 · Recommendation: ⚪ Niche (infosec-oriented; Crawlee/Scrapy better fit for us)
Purpose: OSINT automation / attack-surface mapping.
Why useful: Recon of a supplier's digital footprint (domains, emails, subdomains, socials) for desk-verification.
Difficulty: 🟡 · Recommendation: 👁 Useful for verification/recon workflows
Purpose: Visual workflow automation with native AI nodes. Self-host or cloud.
Why useful: Our automation engine (installed). 400+ nodes, webhooks, MCP, LLM nodes.
Difficulty: 🟢 · Recommendation: ✅ Core (in production)
Purpose: AI agents + MCPs + workflow automation (~400 MCP servers).
Why useful: n8n alternative/companion; strong MCP server catalog for agent tooling.
Difficulty: 🟢 · Recommendation: 👁 Evaluate for MCP/agent-driven automation
Purpose: Developer platform: scripts → webhooks, workflows, internal UIs.
Why useful: Code-first automation + internal dashboards; lightweight n8n alternative.
Difficulty: 🟢 · Recommendation: 👁 Evaluate for internal ops UIs
Purpose: "Agents that monitor and act on your behalf" (IFTTT-style, self-hosted).
Why useful: Monitoring/alerting agents; dated stack (Ruby) vs. n8n.
Difficulty: 🟢 · Recommendation: ✖ (n8n supersedes for our needs)
Purpose: Programmatic data-pipeline scheduling/orchestration (DAGs).
Why useful: For heavy scheduled ETL/scraping pipelines; heavier than n8n for glue.
Difficulty: 🟡 · Recommendation: ⚪ Niche (only if data-engineering scale appears)
Purpose: Workflow orchestration for resilient Python data pipelines.
Why useful: Lighter, more Pythonic than Airflow; good for scheduled enrichment pipelines.
Difficulty: 🟡 · Recommendation: 👁 Evaluate for Python data pipelines (prefer n8n for glue)
Purpose: Durable, retryable, long-running workflow execution (microservice orchestration).
Why useful: For RFQ→order→fulfillment durable state machines that must survive restarts.
Difficulty: 🔴 · Recommendation: 👁 Adopt when durable business processes appear (Phase B/C)
Purpose: BPMN process-orchestration platform.
Why useful: Business-process modeling for procurement approvals; heavier Java footprint.
Difficulty: 🔴 · Recommendation: ✖ (overkill vs. EspoCRM BPM + n8n/Temporal)
Purpose: Build AI agents & chatflows visually (drag-and-drop, LangChain-based).
Why useful: Rapid, no-code prototyping of research agents / internal Q&A tools; lets non-engineers assemble agent pipelines.
Difficulty: 🟢 · Recommendation: 👁 Evaluate for visual agent building / quick internal tools
Purpose: Agent engineering platform; LLM/tool/RAG integrations.
Why useful: Core AI layer — tool abstractions, RAG components, model providers.
Difficulty: 🟡 · Recommendation: ✅ Use (integrations + RAG)
Purpose: Stateful, controllable graph-based agent orchestration.
Why useful: Recommended orchestration for deterministic multi-step procurement research agents; checkpointing.
Difficulty: 🟡 · Recommendation: ✅ Use (primary orchestration)
Purpose: Role-based, collaborative autonomous agent framework.
Why useful: Fast prototyping of "sourcing team" agents; less low-level control.
Difficulty: 🟢 · Recommendation: 👁 Use for experiments/pilots, not the architectural bet
Purpose: Multi-agent conversation framework.
Why useful: Rich multi-agent research; heavier to productionize.
Difficulty: 🔴 · Recommendation: ⚪ Niche (LangGraph preferred for reliability)
Purpose: Lightweight, first-party multi-agent framework (handoffs, tools, guardrails).
Why useful: Minimal, production-focused; great if standardizing on OpenAI.
Difficulty: 🟢 · Recommendation: 👁 Strong alternative to LangGraph (choose per stack)
Purpose: LangChain for JavaScript/TypeScript.
Why useful: If agents live in the Node/Next.js stack.
Difficulty: 🟡 · Recommendation: ⚪ Only if we go TS-first for agents
Purpose: Open-source agentic operating system (agents, memory, multi-platform).
Why useful: General agent runtime with memory; heavier; more for building agent products.
Difficulty: 🔴 · Recommendation: ✖ (overkill; LangGraph fits better)
Purpose: Microsoft 365 Agent SDK (Teams, M365 ecosystem).
Why useful: Only if we go deep into Microsoft 365.
Difficulty: 🟡 · Recommendation: ✖ (not relevant now)
Purpose: Autonomous deep-research agent using any LLM, with web research loop.
Why useful: Best scaffold for our supplier deep-research agent; built-in source-cited reporting.
Difficulty: 🟡 · Recommendation: ✅ Adapt for supplier research
Purpose: Data framework for RAG; document agents & OCR.
Why useful: Strong document-parsing → RAG for dossiers, certs, QC reports.
Difficulty: 🟡 · Recommendation: 👁 Evaluate for document-RAG heavy lifting
Purpose: Text-to-SQL via agentic retrieval ("chat with your database").
Why useful: Natural-language queries over our supplier DB for internal analytics.
Difficulty: 🟡 · Recommendation: ⚪ Niche (nice-to-have internal tool)
Purpose: Conversational data analysis (SQL/CSV/parquet).
Why useful: Internal analytics over supplier data with natural language.
Difficulty: 🟡 · Recommendation: ⚪ Niche (see Vanna)
Purpose: Real-time knowledge graphs for AI agents (bi-temporal memory).
Why useful: Persistent supplier-fact knowledge graph across conversations/research.
Difficulty: 🔴 · Recommendation: 👁 Watch (once agent memory matters)
Purpose: Fast, scalable, local memory/context engine + Memory API.
Why useful: Agent memory/context store (supplier conversation memory).
Difficulty: 🟡 · Recommendation: 👁 Evaluate when agent memory is needed
Purpose: Open-source LLM observability: evals, tracing, prompt mgmt, cost.
Why useful: Recommended for AI tracing, evals, cost control on our agents.
Difficulty: 🟡 · Recommendation: ✅ Use (AI observability)
Purpose: Reference MCP servers (filesystem, web search, fetch, browser, Postgres, memory, GitHub).
Why useful: Ready-made agent tool servers for our agents (web, browser, DB, search).
Difficulty: 🟡 · Recommendation: ✅ Use (standard tool layer)
Purpose: The MCP specification & docs.
Why useful: Standard to wrap our own APIs (EspoCRM, supplier DB, search) as MCP servers.
Difficulty: 🟡 · Recommendation: ✅ Use (spec for wrapping our APIs)
Purpose: Fast, typo-tolerant search engine API with AI/hybrid search.
Why useful: Recommended supplier/product/part search (easy self-host).
Difficulty: 🟢 · Recommendation: ✅ Use (search UI)
Purpose: Open-source Algolia alternative; fast typo-tolerant search.
Why useful: Equivalent to Meilisearch; excellent speed. Choose one.
Difficulty: 🟢 · Recommendation: ✅ Use (alternative to Meilisearch)
Purpose: Distributed RESTful search/analytics.
Why useful: Powerful but memory-heavy; not ideal on 4 GB.
Difficulty: 🔴 · Recommendation: ✖ (until dataset/scale demands it)
Purpose: The PostgreSQL database (mirror).
Why useful: System of record. Recommended primary DB.
Difficulty: 🟢 · Recommendation: ✅ Core
Purpose: Open-source vector similarity search extension for Postgres.
Why useful: Recommended vector store (no extra infra on our Postgres).
Difficulty: 🟢 · Recommendation: ✅ Use (early vector store)
Purpose: High-performance vector database & search engine.
Why useful: Scale-up vector store with payload filtering when needed.
Difficulty: 🟡 · Recommendation: 👁 Move to when pgvector no longer suffices
Purpose: Open-source "search infrastructure for AI" vector DB.
Why useful: Dev-friendly; less production-proven at scale than Qdrant.
Difficulty: 🟢 · Recommendation: ⚪ Niche (pgvector/Qdrant preferred)
Purpose: Cloud-native vector database for large-scale ANN search.
Why useful: Powerful but heavy distributed ops; overkill for us now.
Difficulty: 🔴 · Recommendation: ✖ (until large scale)
Purpose: MongoDB document DB.
Why useful: Only if heterogeneous dossier JSON demands it; Postgres JSONB likely suffices.
Difficulty: 🟢 · Recommendation: ⚪ Niche (Postgres preferred)
Purpose: Python library making data loading/ETL easy.
Why useful: Ingest scraped/API supplier data into Postgres cleanly.
Difficulty: 🟡 · Recommendation: 👁 Evaluate for ingestion pipelines
Purpose: Open-source data movement (ELT) across APIs/databases/files.
Why useful: Standard connectors for many sources; heavier platform.
Difficulty: 🟡 · Recommendation: ⚪ Niche (dlt/CloudQuery may suffice)
Purpose: Declarative, code-first data integration engine.
Why useful: Singer-based taps/targets for ELT.
Difficulty: 🟡 · Recommendation: ⚪ Niche (dlt preferred)
Purpose: Data pipelines for cloud config/security data (asset inventory, CSPM).
Why useful: Less relevant (cloud infra, not supplier data). Optional infra asset inventory.
Difficulty: 🟡 · Recommendation: ✖ (out of scope for now)
Purpose: Flow-based data processing/automation.
Why useful: Powerful but heavy (Java); overkill vs. n8n/dlt for our scale.
Difficulty: 🔴 · Recommendation: ✖ (overkill)
Purpose: ETL for documents → structured data (PDFs, HTML, docx, etc.).
Why useful: Recommended for parsing certs, QC reports, catalogs, emails into structured data for RAG.
Difficulty: 🟡 · Recommendation: ✅ Use (document parsing)
Purpose: Detect/extract text & metadata from 1000+ file types.
Why useful: Lightweight text extraction across file types (backend service).
Difficulty: 🟡 · Recommendation: ⚪ Niche (Unstructured likely sufficient)
Purpose: Self-hosted document management: scan, index, archive (OCR).
Why useful: Archiving invoices, certs, contracts, QC reports with OCR + tags.
Difficulty: 🟢 · Recommendation: 👁 Evaluate as a document archive layer (optional)
Purpose: Fast way to build & share Python data apps.
Why useful: Quick internal dashboards (supplier scoring, RFQ analytics).
Difficulty: 🟢 · Recommendation: 👁 Use for internal analytics dashboards
Purpose: Build/demo ML & agent apps quickly.
Why useful: Prototype agent UIs / demos.
Difficulty: 🟢 · Recommendation: ⚪ Niche (prototyping only)
Purpose: Build admin panels, internal tools, dashboards; connects to DBs & APIs.
Why useful: Fast internal ops tools wired to Postgres/EspoCRM.
Difficulty: 🟢 · Recommendation: 👁 Evaluate for internal admin/ops UIs
Purpose: Open-source foundation for building internal tools/apps.
Why useful: Similar to Appsmith; AGPL note. Internal ops dashboards.
Difficulty: 🟢 · Recommendation: 👁 Alternative to Appsmith
Purpose: Flexible backend: DB → headless CMS/admin panels/APIs.
Why useful: Could serve as a lightweight admin/API layer over Postgres.
Difficulty: 🟢 · Recommendation: ⚪ Niche (we'll likely use our own backend)
Purpose: Open-source communication infrastructure for products (email, SMS, in-app, push).
Why useful: Multi-channel notifications for buyers/suppliers (email + Telegram/Slack/WhatsApp).
Difficulty: 🟡 · Recommendation: 👁 Evaluate for notification hub (or use n8n)
Purpose: "The Postgres development platform" — managed Postgres, auth, storage, realtime.
Why useful: Auth + Postgres + APIs for our app stack (self-host option exists).
Difficulty: 🟢 · Recommendation: 👁 Strong option for app auth/backend services
Purpose: Open-source identity & access management (SSO, OIDC, SAML).
Why useful: Centralized login for CRM/portal/agents when multiple apps + SSO needed.
Difficulty: 🔴 · Recommendation: 👁 Add when SSO/multi-app auth is needed (Phase B/C)
Purpose: Easy Docker/Kubernetes management UI.
Why useful: Simple container management for our self-hosted stack.
Difficulty: 🟢 · Recommendation: ✅ Use (container management)
Purpose: Progressive Node.js backend framework.
Why useful: If we choose a TypeScript backend (vs. FastAPI).
Difficulty: 🟡 · Recommendation: 👁 TS-backend option
Purpose: Web APIs for Django.
Why useful: If we choose Django (admin + CRUD heavy backend).
Difficulty: 🟡 · Recommendation: 👁 Django option (FastAPI preferred)
Purpose: Light, flexible ASGI framework (FastAPI-class).
Why useful: FastAPI alternative; similar ecosystem.
Difficulty: 🟡 · Recommendation: ⚪ Niche (FastAPI preferred for maturity)
Adopt now (core): EspoCRM (have it), n8n (have it), PostgreSQL + pgvector, Crawlee(-python), Unstructured, Langfuse, LangGraph + LangChain, gpt-researcher (adapt), MCP servers, Meilisearch/Typesense, Portainer.
Watch/evaluate (as we scale): Twenty, ERPNext (plan B), Temporal, Qdrant, Supabase, Keycloak, Novu, Appsmith/ToolJet, Streamlit.
Avoid/niche now: Elasticsearch, Milvus, MongoDB, Apache NiFi, Camunda, Autogen, Eliza, Airflow (unless data-scale), suiteCRM, Odoo (unless full ERP).