home strategic briefing
spine sovereignty map motion map lexicon identity graph provenance physics engine
Vendor vs Build · Sovereignty Decision Architecture

Where Do You Require Sovereignty?

This is not a procurement question. It is a control question. Vendors can supply sensory input. They cannot define judgment. Map each layer against sovereignty requirements.

Portfolio-Level Implications
At portfolio scale, vendor sprawl becomes cost and governance risk. You will need centralized telemetry normalization, shared weighting logic, and a shared feedback engine — with company-specific execution tooling. The architectural decision: build a central adjudication core and allow per-asset tooling variation, or standardize stack across portfolio.
Vendor = sensory input Build = judgment authority Economic weighting → build Probability modeling → build Capital allocation → build Commodity data → vendor acceptable
Never Vendor
Build Logic
Hybrid — Vendor Infra, Your Logic
Vendor Acceptable
Build
Strategic
Layer 01 · Immune System
Revenue Feedback & Reweighting
You cannot outsource your immune system. Prediction error correction and capital reallocation rules are strategic. You may use BI tools to visualize, but the correction logic, error aggregation windows, and reweighting triggers must be proprietary.
Sovereignty Rules
✕Vendor cannot define correction triggers
✕Vendor cannot set reweighting thresholds
✓Vendor BI for dashboards acceptable
✓Vendor data warehouse acceptable
Hybrid
Infra: Vendor
Logic: Build
Layer 02
Orchestration & Velocity
Mostly vendor infrastructure — CRM, marketing automation, sales engagement, routing tools. But routing logic and threshold triggers must be yours. Otherwise velocity becomes tool-constrained rather than economics-constrained.
Sovereignty Rules
✓Vendor CRM (Salesforce, HubSpot)
✓Vendor MAP (Marketo, Pardot)
✓Vendor engagement (Outreach, Salesloft)
✕Vendor cannot define routing logic
✕Vendor cannot set velocity thresholds
Hybrid
Raw fuel
Telemetry Ingestion · Between Layers 02–03
Telemetry Ingestion Layer
Vendors acceptable here — telemetry is raw fuel. Intent networks, technographic crawlers, enrichment APIs, behavioral tracking. But vendor data must be normalized and adjudicated internally. Never allow vendor scoring to bypass your Signal Engine. Vendor provides raw signal. You provide weighting authority.
Vendor Examples
✓Bombora, G2 (intent)
✓BuiltWith, HG Insights (techno)
✓ZoomInfo, Clearbit (enrichment)
✕Vendor scoring must NOT bypass L03
Build
Core IP
Layer 03 · Adjudication
Signal Interpretation Engine
Core logic = build. This is where competitive advantage lives. If a vendor defines probability modeling, you become dependent on black-box inference. In PE-backed systems, that is risk. Data science can leverage vendor analytics platforms, but probability weighting architecture must be yours.
Sovereignty Rules
✕Vendor cannot define probability model
✕Vendor cannot set signal weights
✕Vendor cannot control decay constants
✓Vendor analytics infra (Snowflake, dbt)
✓Vendor ML platforms (infra only)
Build
Proprietary
Layer 04
ICP Economic Clustering
Build the logic. You may use BI tooling, but clustering criteria must be proprietary. Your Revenue Density Score is your capital allocation engine. If a vendor defines segmentation heuristics, you lose differentiation. Tooling can be external. Clustering logic cannot.
Sovereignty Rules
✕Vendor cannot define cluster criteria
✕Vendor cannot set density formulas
✓Vendor BI (Looker, Tableau, Hex)
✓Vendor data infrastructure
Never
Internal truth
Layer 05 · Anchor Mass
P&L Economic Gravity
Never vendor. This is internal truth. ARR math, CAC constraints, margin targets — this must live in your own systems. Even if finance tooling is external, the logic is yours. No debate.
Sovereignty Rules
✕No vendor defines ARR logic
✕No vendor defines CAC constraints
✕No vendor defines margin targets
✕No vendor defines LTV:CAC thresholds
~Finance tooling external OK (NetSuite, etc.)
Decision Framework
When to vendor vs when to build
Vendor Acceptable Where
·Data is commodity
·Infrastructure is plumbing
·Scale is expensive to build
·No proprietary logic at stake
·Switching cost manageable
Build Required Where
·Economic weighting occurs
·Probability modeling occurs
·Capital allocation decisions occur
·Governance constraints exist
·Competitive differentiation at stake
Screening Response — Board-Ready
"I would vendor commodity telemetry and infrastructure, but retain control over economic weighting, probability modeling, and capital reallocation logic. That's where differentiation and governance risk live."
Portfolio Architecture Tradeoff
Standardization vs Flexibility
Standardize Stack Across Portfolio
Increases leverage
Unified data model across assets
Shared weighting logic compounds
Lower total vendor cost
Slower acquisition integration
Requires migration investment
May not fit edge-case business models
Central Core + Per-Asset Tooling
Faster acquisition velocity
Preserves acquired team workflows
Lower integration risk
Vendor sprawl increases over time
Data normalization complexity
Weaker cross-asset learning signal
Higher total cost at scale
Foundational Question
Is the ambition here to build a portfolio-level Revenue OS platform that compounds across assets — or to optimize individual companies one by one? Because the vendor vs build calculus changes dramatically depending on that ambition.