How I Built a Unified Platform Without a Data Warehouse (and Didn't Regret It)

July 12, 2026

I used to assume "unified platform" automatically meant "build a data warehouse." But in my case, a warehouse would've added cost, latency, and a second copy of truth we'd constantly reconcile. We needed something different: a single place for product, ops, and reporting to agree on customers, subscriptions, and activity-without waiting for nightly ETL.

Here's what I built instead, and how it held up in the real world.

The Core Idea: Unify at the Interface, Not the Storage

Rather than centralizing all data into a warehouse, I centralized access through a thin "unification layer." Concretely, that meant:

A canonical customer model (the IDs and rules everyone agrees on)
A set of APIs that serve "golden records" in real time
A small operational store for just what we needed to compute quickly (not a full replica)

Example: Customer data lived in three places-Stripe (billing), HubSpot (CRM), and Postgres (product). Instead of copying everything, we created a single customer identity map:

primary_customer_id (our internal ID)
stripe_customer_id
hubspot_contact_id
email + domain matching rules (with human override)

When the app or a dashboard asked "who is this customer and what plan are they on?", it hit one endpoint, not three systems.

The Building Blocks I Actually Used

This approach only works if you're disciplined about contracts and consistency. My stack looked like this:

1) API Gateway + Service Layer
I built a "Customer Service" and "Subscription Service" that expose canonical endpoints like:

`GET /customers/{id}` (returns merged profile)
`GET /customers/{id}/entitlements` (computed access rights)
`GET /subscriptions/{id}` (current status + next invoice)

2) Event-Driven Sync for Change Data
Instead of ETL jobs, I used events to react to changes:

`stripe.invoice.paid` updates subscription status
`hubspot.contact.updated` updates sales attributes
`user.created` in Postgres creates identity links

A lightweight event bus (plus idempotent consumers) kept the unified layer current within seconds.

3) Operational Cache / Read Model (Small, Purposeful)
Some queries were too slow to compute on the fly (like "MRR by plan for the last 30 days"). I didn't build a warehouse; I built a narrow read model:

daily subscription snapshots
customer-to-plan history
a metrics table updated incrementally from events

This was stored in Postgres. The key rule: if we couldn't explain why a table existed in one sentence, it didn't belong.

Reporting and "Single Source of Truth" Without the Pain

The biggest objection I hear is: "How do you do analytics?" Answer: I separated operational truth from analytical convenience.

Operational truth: APIs + canonical models + real-time state
Analytical convenience: a few curated tables/views built from events and snapshots

Practical example: our support team needed a "Customer 360" view. Instead of giving them a BI tool pointed at a warehouse, we shipped an internal page powered by the unified APIs:

latest payment status from Stripe events
active plan/entitlements from Subscription Service
last-seen activity from product events

For finance, we provided a small set of reconciled exports (CSV + scheduled delivery) generated from the same read model.

The tradeoffs are real: this takes more engineering rigor up front (schemas, idempotency, monitoring). But the payoff is huge-fresher data, fewer "why does the warehouse disagree?" meetings, and a platform that feels unified because users experience it as unified.

If you're early-stage or operating in real time, you might not need a warehouse yet. You might just need a clear contract for truth-and a smart place to serve it.

Search This Blog

tylers-blogger-blog