Build vs Buy Startup Intelligence: A Self-Hosted Entity Graph

Do not build a startup database merely to avoid paying for one. Build a self-hosted intelligence graph when your recurring questions require joins, source combinations, confidence rules, or private annotations that a general-purpose platform cannot model. For broad coverage and occasional lookup, buying access is usually cheaper.

This is the build-vs-buy framework I wish I had before creating EntityScope, a local DuckDB knowledge base queried by agents through the Model Context Protocol (MCP). The useful part was not “owning the data.” It was owning the entity model, provenance rules, and query surface. The expensive part was everything required to keep those trustworthy.

Reviewed July 28, 2026. Measurements below come from the local EntityScope database and source code at commit 41f5abf. They describe a working prototype, not a validated replacement for a commercial data provider.

The five-whys diagnosis

1. Why was startup research slow? Each answer required opening several sources and copying facts into one note.
2. Why did the sources not compose? They used different identifiers, schemas, coverage, and update schedules.
3. Why did automation still produce uncertain answers? It could not show which source supported each field or how recently that field was checked.
4. Why did a new dashboard not solve it? The bottleneck was resolution and provenance, not presentation.
5. Why build a local graph? To make the recurring joins, confidence policy, and agent interface first-class parts of the system.

The root problem was not that commercial databases are bad. It was that my workflow needed a different data product: a narrow, auditable view of Berlin and Munich companies that could combine public, curated, and private research.

Build, buy, or use a hybrid?

Decision factor	Buy	Build	Hybrid
Coverage	You need many markets immediately	A narrow geography or domain is sufficient	Broad provider plus specialist enrichment
Query shape	Standard filters answer most questions	Questions require custom joins or rules	Provider facts feed local decision models
Evidence	Provider attribution is sufficient	You need provenance per field	Preserve both provider and local sources
Private context	Little or none	Internal notes are a major differentiator	Keep private context local
Operations	No team for ingestion and quality work	You can own freshness and incident response	Build only the differentiating layer

A useful default is hybrid. Buy or consume authoritative coverage where it is economical; normalize only the fields that drive a repeated decision; add sources the provider does not include; and keep private annotations behind your own access boundary.

What EntityScope actually contains

The current DuckDB file is 8 MB. A read-only audit on July 28 found:

Table	Rows	Role
entities	1,010	Canonical legal-entity spine
entity_sources	8,018	Field, source, confidence, URL, verification time
prospects	333	Curated Berlin startup profiles
outreach_contacts	394	Private research overlay, including 150 Munich records

The counts look substantial, but completeness is uneven. Employee and founding-year fields are present for almost all legal entities; EU contribution fields are empty. Of 8,018 provenance rows, 8,000 came from the initial Berlin dataset, 16 from Wikidata, and 2 from manual web research. All were last checked on May 27, 2026.

That means three claims in the original version of this article were not defensible:

• The graph is not real-time; it is a snapshot with freshness machinery.
• It has not been shown to be more accurate than commercial datasets.
• The CORDIS and GitHub enrichment modules exist, but their fields are not yet populated in the audited database.

This distinction—implemented pipeline versus populated evidence—is exactly why field-level provenance matters.

The minimum useful architecture

Public and curated sources
        │
        ▼
Source adapters ──► resolver ──► canonical entities
        │                            │
        └──────────────► field-level provenance
                                     │
Private prospect context ────────────┤
                                     ▼
                         parameterized query layer
                                     │
                                     ▼
                               MCP tools for agents

1. Start with a stable entity spine

Choose the most reliable identifier available for the domain: a registration number, repository owner, grant-participant identifier, or another durable key. Names are aliases, not primary keys. Entity resolution should produce a match decision and preserve the inputs that justified it.

2. Store assertions, not just values

A row saying employee_count = 42 loses the information needed to trust it. Store source, source URL, observed time, confidence, and transformation. When two sources disagree, keep both assertions and let a policy choose the current value.

3. Treat open data as inputs with contracts

CORDIS provides EU research-project data through bulk downloads and linked open data. Wikidata exposes a SPARQL endpoint for structured queries. GitHub provides a documented API, but its rate limits and secondary limits are operational constraints. Every adapter needs a license check, retry policy, raw-input retention rule, and freshness expectation.

4. Keep natural language outside the database boundary

EntityScope first translates a question into a bounded filter object, then builds parameterized SQL. The database never executes model-generated SQL. Common patterns such as city, employee range, founding year, industry, funding, and result limit have deterministic parsers; an LLM is an optional fallback.

5. Make freshness queryable

“Updated weekly” is not a property of the whole database. Each source and field ages differently. The system should expose last verification time, stale-field counts, and the policy that marks a record unfit for a given decision.

A build-cost model that avoids vanity engineering

Compare annual cost, not subscription price:

Annual build cost =
  initial engineering
  + source maintenance
  + quality review
  + compute and storage
  + incident and compliance work

Annual value =
  avoided licenses
  + research time saved
  + decisions enabled by unique joins
  + value of private context kept local

Only the “unique joins” and private context are defensible strategic advantages. Re-creating commodity profiles is maintenance work. If a provider can answer the question with an export or API, integrate it. If the question depends on your own taxonomy, confidence rules, or historical observations, build that layer.

Acceptance criteria before expanding sources

• Define 20 representative research questions before designing tables.
• Measure how many end with a sourced answer and no manual lookup.
• Spot-check a fixed sample against authoritative sources.
• Track false joins separately from missing joins; false joins are usually more damaging.
• Reject answers when required fields are stale or below a confidence threshold.
• Add a source only when it improves a named query, not because it is available.

The technical implementation—schema, MCP surface, query translation, and limitations—belongs in the agent-first EntityScope architecture article. Signal models built above the graph belong in the startup-signals article. This page owns the build-vs-buy decision.

The decision

Build a self-hosted entity graph when the model of truth is your differentiator. Buy data when coverage is the differentiator. Use a hybrid when you need both.

EntityScope is useful today as a narrow, agent-queryable research store with explicit provenance. It has not yet earned the stronger claim that it replaces a commercial startup database. That claim should come only after freshness, accuracy, query-resolution rate, and operational cost are measured over time.