Enterprise intelligence for founders.
See it, analyze it, decide on it.

1. What enterprise intelligence actually is

Enterprise intelligence is three layers of visibility: what customers are doing, whether the system is healthy, and whether the P&L is moving. Not one tool, three disciplines.

"Enterprise intelligence" gets used to mean many things. The one that matters for founders: the combined discipline of product analytics (customer behavior), infrastructure observability (system health), and business intelligence (financial and operational metrics), tied to decisions rather than to dashboards.

The confusion is that vendors want to sell each of those as one product. In practice they are three distinct stacks that share underlying primitives (events, logs, metrics) and one destination (your data warehouse) but serve different questions, different consumers, and different urgency levels.

The right mental model: instrumentation is cheap, storage is medium, decisions made from the data are the real cost and the real value. Optimize for the last one; the first two are means to an end.

2. When to invest, when not to

Every founder buys the stack too early or too late. The heuristic is not stage; it is questions you cannot answer with what you have.

Sentry from week one. Errors happen from the first user; every hour without visibility is time your customers see bugs before you do. This is the one thing that is always worth setting up on day one.

Product analytics from the first ten paying users. Not before (you have no volume) and not after (you have already made retention decisions blind). PostHog is the pragmatic default.

Real BI from about $100K ARR. Before that, a spreadsheet updated weekly is faster than any BI tool. After that, cross-team disagreements about the numbers start to cost more than a Metabase instance.

Real infra observability the day you have a customer with an SLA. Not before (three services do not need Datadog); not after (an outage without traces is a 3-AM guessing game).

The single test: if a question about your business is being answered "I do not know" or "let me check with engineering" more than once a week, that is the question your intelligence stack should be answering. Buy or build to answer that question, not to fill out a category.

3. The three layers

Every intelligence tool falls into one of three layers. Confusing them is where wasted spend comes from.

All three layers eventually converge in the data warehouse (or should). Product events, infra metrics, and business numbers joined in one query is where the insights that spreadsheets cannot reach start to live.

4. Metrics, logs, traces (and friends)

The five signal types every stack collects. Each is cheap to start, expensive at scale, and useful for a different question.

Signals grow at different rates. Metrics are near-free; logs and traces cost real money at scale; events cost per-user per-month; session replays are storage-heavy. Every observability bill surprise traces to one of these lines growing faster than the team expected. Instrument tag-cardinality budgets and sampling rates from the start.

5. Product analytics stack

One tool for the whole product analytics job is fine for most teams. Stitching three "best of breed" tools is usually worse.

Instrument the decisions, not everything. Every event carries cost (storage, cardinality, cognitive load). Start with the three or four events that map to activation and retention; add more as questions come up, not as insurance.

Warehouse-native analytics is the important shift. PostHog, Amplitude, and Mixpanel all now offer sending events straight to your warehouse (Snowflake, BigQuery, Redshift). Use it. Product analytics locked inside the tool that captured it is a limitation you will regret at your first cross-tool cohort analysis.

6. Infrastructure observability

Sentry always. Everything else, only when the question asks for it.

OpenTelemetry is not optional. It is the vendor-neutral instrumentation standard, supported by every serious tool. Writing to a proprietary SDK in 2026 is choosing lock-in with no upside. Start OTel-first even if you send data to Datadog on day one, so you can swap later without touching application code.

Sampling saves the bill. A trace on every request at high volume is a bill you cannot afford. Head-based sampling (decide at the trace start) is easier; tail-based sampling (decide after you see the whole trace) is smarter. Both are supported by mature vendors. Turn one on before your Datadog bill catches you off guard.

7. Business intelligence

BI is where the business runs on data or does not. The tool matters less than the metric definitions behind it.

Metric definitions matter more than the visualization. A dashboard with the right numbers computed the wrong way is worse than no dashboard. Define MRR, ARR, retention, and cohorts in one place (a semantic layer, section 9) and read them from every downstream tool.

Governance from day one. Tag every dashboard with an owner, a business area, and a last-verified date. Prune anything with no views in 90 days. Dashboards that outlive their purpose become the source of the wrong number in an important meeting.

8. The data warehouse question

Every startup gets a data warehouse eventually. The choice matters less than the discipline around it.

Start with Postgres or BigQuery. The former if your app is already on Postgres and you want the analytical mirror close. The latter if you want serverless, on-demand, and are already in Google Cloud. Snowflake is excellent and probably not what you should start with unless you already have a team.

Move data with a purpose-built tool. Fivetran, Airbyte, or Stitch for ingestion; dbt for transformation. Rolling your own ELT is a rite-of-passage cost most startups pay twice before stopping.

Cost discipline from month one. Bytes-scanned pricing (BigQuery) and warehouse-hours pricing (Snowflake) both punish sloppy queries. Enforce partition and cluster on every table; test cost in CI on every dbt model.

9. The metric layer

Define metrics once, use everywhere. The layer that ends "which MRR number is right?" as a weekly argument.

A semantic layer (dbt Semantic Layer, Cube, MetricFlow) is a single place where every business metric is defined: MRR calculation, active-user definition, cohort cut rules. Every dashboarding tool, every notebook, every AI-generated query reads from the same definitions.

Adopt it the day two dashboards show two different MRR numbers and both teams insist they are right. Which will happen sooner than the team thinks.

Start small. Define the ten metrics that show up in every leadership review. Roll out to more only after those ten are stable and used. A semantic layer that tries to model every possible aggregation on day one becomes a documentation project no team finishes.

10. Datadog vs Sentry vs Honeycomb vs New Relic

The four names that dominate infra observability. Each is best at a different question.

Sentry owns error tracking. Cheap, focused, easy to instrument. Start here always; keep it forever even if you add other tools around it.

Datadog owns breadth. Metrics, logs, APM, traces, RUM, security, all in one product. The default enterprise pick. Excellent depth, painful pricing at volume.

Honeycomb owns tracing. The best product for teams debugging genuinely distributed systems. Overkill for a three-service startup; a lifesaver for a company with real perf mysteries.

New Relic owns simpler pricing than Datadog. Reasonable if you want a single vendor and Datadog\'s bill is a hard blocker. Product depth is not as strong.

Grafana + Prometheus + Loki + Tempo owns cost. Open source, powerful, real operational overhead. The right pick when you have DevOps capacity and cost pressure, and the wrong one when you have neither.

11. PostHog vs Amplitude vs Mixpanel

The three names that dominate product analytics. Each is a reasonable pick for a different team shape.

PostHog is the pragmatic default. Open-source, all-in-one (analytics + session replay + feature flags + A/B tests + surveys), self-host or cloud, warehouse-native. Wins on breadth and price at startup and mid-market scale.

Amplitude is best-in-class for cohort analysis. Wins on depth for teams where analytics is a full-time job and PostHog\'s ceiling is being hit. Priced for scaled companies.

Mixpanel is the classic. Strong event analytics, generous free tier, feels a step behind PostHog on modern DX. Reasonable if you are already inside it; not necessarily the first pick for a new build.

GA4 is for pageviews on marketing sites where you need Google Ads attribution. It is not a product analytics tool. Pretending it is has cost more startups than any other analytics mistake.

12. Metabase vs Looker vs Tableau vs Hex

The four names that cover most BI needs. Pick the one that matches your team\'s SQL comfort and your budget.

Metabase is the pragmatic default at startup scale. Open source, self-hostable, visual query builder plus SQL, decent dashboarding. Good until you have a scaled analytics team who wants a real modeling layer.

Looker is the enterprise BI default. Strong modeling layer (LookML), Google-owned, expensive, requires a data engineer to operate well. Right pick for scaled teams; overkill before.

Tableau is the pre-cloud visualization craftsman\'s choice. Still strong, feels heavy in a modern warehouse-first stack. Reasonable in companies where Tableau expertise already exists.

Hex / Mode are notebook-style analytics platforms. Great for exploration and one-off reports, less good as an always-on BI layer. Complement Metabase or Looker; do not replace them.

13. SLOs + error budgets

SLOs are the reliability discipline that survives every team change. Adopt them the day you have customers who depend on you.

An SLO (service-level objective) is a target: "99.9% of requests will succeed within 500ms over 30 days". An error budget is the inverse: 0.1% of requests are allowed to fail; when you have burned through the budget, you slow down and fix reliability instead of shipping features.

Practical defaults for most B2B SaaS: 99.9% availability (~43 minutes of downtime per month), 500ms p95 latency for user-facing APIs, 99% success rate for background jobs over 24 hours. Higher only if you can defend it.

Every alert traces back to an SLO. If an alert does not correspond to burning through the error budget faster than expected, it is a dashboard, not an alert. This is the single most useful rule for cutting alert fatigue.

14. Alerts vs dashboards

Alerts wake humans. Dashboards inform humans. Confusing the two is the root of alert fatigue.

An alert must correspond to a specific human action. "Deploy fix X", "roll back last change", "call on-call at vendor Y". If the action is "check the dashboard", it is not an alert; it is a dashboard.

The five metrics that should page: availability below SLO (burn), latency p95 above threshold (SLO burn), error rate spike (customer impact), critical background job failure (data integrity), and prompt-injection or security anomaly (breach). Anything else is a dashboard or a report.

Every alert has a runbook. A named human owns it. A written procedure links from the alert to the fix. Alerts without runbooks are alerts that will be muted after the third time they wake someone up at 3 AM for nothing actionable.

Prune quarterly. Every alert that fired more than three times without being actionable in the last quarter gets cut or has its threshold raised. Alert fatigue is not a fact of life; it is a symptom of a team that has stopped pruning.

15. Compliance + enterprise readiness

Compliance signals are what enterprise buyers actually check. Not the certificate; the evidence behind it.

SOC 2 Type 2 is the practical benchmark for US mid-market and up. Type 1 opens the door; Type 2 keeps it open. Modern compliance-automation tools (Vanta, Drata, Secureframe) cut the cost from six-figure consulting engagements to five-figure SaaS plus a few months of internal work.

The evidence is what matters. Enterprise buyers do not just want the badge; they want to see the controls actually operating: encrypted at rest, MFA on production, access reviews quarterly, backups tested, incident response documented. Build the evidence first; the certification is what you show for it.

16. Security telemetry

Security is intelligence you hope never gets consulted. Instrument it before you need it.

Authentication and authorization events. Every sign-in, every failed sign-in, every permission change, every admin action. Retain for at least a year; enterprise buyers audit it, and incident response depends on it.

Data access logs. Every read of sensitive tables and every export, tagged with user, purpose (if known), and destination. This is the difference between "did we breach data?" being answerable and being a nightmare.

Endpoint security signals. Employee laptops running an EDR (CrowdStrike, SentinelOne, or Sophos), device management via MDM (Kandji, Jamf, or Intune), and every developer laptop hitting production going through a bastion or VPN with logging.

SIEM once you cross ~$5M ARR (Panther, Elastic, Splunk, or open-source Wazuh). Before that, well-configured Datadog / CloudTrail / and audit logs cover most of the ground at a fraction of the cost.

17. AI in intelligence tools

Every observability and BI vendor has shipped AI features. Some are useful. Most are marketing.

What actually works in 2026: natural-language to SQL (real productivity for analysts), auto-summarization of long incident traces (real time savings on-call), root-cause hint generation from correlated metrics (works when it works, silent when it does not), and anomaly detection (useful for known-unknowns, noisy for unknown-unknowns).

What does not work yet: fully AI-driven root-cause analysis (still needs a human to interpret), "self-healing" incident response (marketing, not reality), and AI-generated dashboards that people trust for decisions without review (great for first draft, dangerous as final answer).

The right stance: use AI as an accelerant for the humans reading the data, not as a replacement for them. The tools that will win in 2026 treat AI as a copilot, not an operator.

18. Cost economics

Every observability bill grows faster than the team expects. Every BI bill grows more slowly. Both need discipline.

Observability cost is dominated by three things: logs (volume), metrics cardinality (tag combinations), and traces at high request volumes without sampling. Cap each; alert on each. Every observability bill blowout is one of these three.

Warehouse cost is dominated by inefficient queries. A single hourly query with a bad partition key can cost more than the rest of the warehouse combined. Enforce dbt tests on cost, alert on top-10 query cost, and put per-user query budgets on ad-hoc access.

A pragmatic startup stack: Sentry ($26 to $80/mo) + PostHog Cloud ($0 to $450/mo depending on volume) + Metabase self-hosted ($30/mo of infra) + BigQuery / Postgres (~$50 to $500/mo depending on volume) + basic Grafana Cloud ($0 to $100/mo). Total: $100 to $1,200/mo at low-single-digit-million ARR. Fine for years.

The enterprise version of the same coverage: Datadog ($3K to $30K/mo) + Amplitude ($1K to $10K/mo) + Looker ($5K to $50K/mo) + Snowflake ($5K to $50K/mo). Total: $10K to $100K+/mo. The gap is not capability; it is which line item you would rather explain to the board.

19. Team + workflow patterns

The stack works when someone owns it. Every unowned dashboard rots; every unowned alert eventually gets muted.

Ownership per layer. Product analytics owned by product ops or growth. Infra observability owned by engineering. BI owned by finance ops or a data team. Cross-cutting metrics owned by whoever writes the semantic layer. Unowned means undefended.

Data engineer at ~$1M ARR, when warehouse infrastructure needs someone to think about it. Data analyst at ~$3M to $5M ARR, when dashboards need governance and decisions are cross-functional. Do not hire a "head of data" before there is data infrastructure to head.

Weekly data reviews from ~$1M ARR. One hour, one owner, top ten metrics, one decision. Not a status meeting; a decisions meeting. If nothing changes after the meeting, cancel the meeting.

Runbooks change shape. Instead of "if metric X is high, do Y", they become "if metric X is high, load dashboard D, check downstream services in order, and page on-call at vendor V if pattern P". Runbooks that assume everyone knows which dashboard is authoritative do not survive a team change.

20. Failure modes

The eight failures every intelligence stack eventually hits. Design for them or they will design your next incident retro.

• Metric explosion. Cardinality gets out of hand (a user_id label on every metric). The bill quintuples overnight. Enforce a tag-cardinality budget in every service.
• Alert fatigue. Every metric becomes an alert; on-call ignores everything. Cut alerts by 80%; keep only what should wake a human. Everything else is a dashboard.
• Dashboard sprawl. Every team makes ten dashboards; nobody knows which is authoritative. Instrument dashboard usage; delete anything with zero views in 90 days.
• Instrumentation drift. Old event names, renamed fields, deprecated properties still fire alongside new ones. Version your event schemas and deprecate loudly.
• PII in traces or events. Personal data ends up in an observability system that was not audited to hold it. Scrub at ingestion; block on schema; audit quarterly.
• Vendor lock-in surprise. Two years in, you cannot leave because everything is in one vendor's query language. Build against OpenTelemetry; keep raw events in your warehouse.
• Data-warehouse cost drift. One badly written query runs hourly and burns thousands. Set query-cost alerts, dbt tests on query cost, and per-query budgets.
• Analytics as decoration. Nobody actually reads the dashboards; decisions still get made on gut. The number that matters is decisions-made-from-data, not dashboards-published.

21. Migration paths

Every intelligence tool gets swapped eventually. The teams that migrate well do it one layer at a time.

Spreadsheet to real BI. Do not rebuild the spreadsheet in Metabase; rebuild the questions the spreadsheet answered. Kill the spreadsheet only after the dashboard has been reviewed and approved for two months in parallel.

Postgres to real warehouse. Fivetran / Airbyte to move data, dbt to model. Run both in parallel for a month; validate that the numbers match. Cut over one dashboard at a time; retire the Postgres path only when every consumer is on the warehouse.

Proprietary SDK to OpenTelemetry. Start OTel-first for every new service. Migrate existing services opportunistically, not as a project. Keep the vendor SDK for legacy services until you touch them anyway.

Datadog to Grafana (cost). The migration that happens when the Datadog bill crosses a threshold and the team has DevOps capacity. Pilot with one service, prove parity, expand. Never migrate all services at once; you will lose visibility for weeks.

The single failure mode of migrations: the new tool silently misses a class of signal the old tool caught. Instrument both, diff the outputs, page on mismatch. Do not trust the ports.

22. Hype vs signal

The parts of the enterprise-intelligence discourse that will still matter in 2027, and the parts that will not.

23. FAQ

Fifteen questions founders actually ask about enterprise intelligence in 2026.