Solutions designed with your goals in mind

Filed Needed One View of Every Prospect From First Click to Paid Workspace

12 to 1 Systems

Unified into one warehouse, zero manual exports

1 model

Full Lead to Cash journey, defined once

30 min

Refresh cadence, deals and trials always current
"Schema evolution is not a nice to have. When a product deploys daily and pipelines break silently, stakeholders make decisions on numbers nobody has checked. Building schema evolution into the foundation before anything else meant every deploy became safe instead of a liability."

At a glance

  • Marketing, sales, product, and finance data from 12 systems unified into Snowflake
  • A Lead to Cash model tracing every prospect from first session to paying workspace
  • Trial workspaces scored by engagement, so account managers know who to call

Vero by Datum Labs built the unified data foundation for this client. Filed is a product-led AI tax platform where users file their tax returns through a self-service workspace. Prospects enter through ads, organic, and referrals, start free trials, and convert to paying workspaces. The company manages both a marketing funnel and a product trial base simultaneously across 12 data systems.

Prospects came in from ads, organic, and referrals. Trials started. Some converted, some went quiet. The team could see neither journey end to end, nor the deal moving from first click to paid, nor the trial moving from signup to actual use.

Nothing about this stack was broken. HubSpot tracked leads and deals cleanly. Postgres ran the product without issue. Three marketing platforms ran their campaigns on schedule. None of that mattered on the days a product release reshuffled the Postgres schema just enough to break a report nobody had checked yet.

The Problem With Two Invisible Journeys

As trial volume grew, so did the difficulty of answering two questions at once: which prospects were actually becoming paying workspaces, and which trials were engaging with the product versus sitting idle on free credits. Account managers found out a trial had gone cold only after it already had.

Any product-led company managing both a funnel and a trial base eventually asks these same questions. What this team could not do was answer them without a spreadsheet built after the fact.

Every system Filed relied on, connected into one warehouse:

Domain Sources What we track
Marketing Google Ads, Facebook Ads, LinkedIn Ads, GA4, social pages Spend, sessions, conversions, engagement
Sales and CRM HubSpot Leads, MQLs, meetings, deal stages
Product Postgres backend, Postgres AI DB, PostHog Workspaces, tax preps, credits, trial funnel
Finance Sequence Invoices, billing, subscriptions

The data existed. The problem was connection. Without a warehouse underneath, every deploy could silently break a report, and nobody would know until a stakeholder asked why the numbers looked wrong.

Why the Standard Answer Did Not Fit

Hiring a data engineer to connect HubSpot and Postgres is the obvious move. It is also the slow one. A new hire needs months to ramp up and still has to relearn the schema after every deploy, with no team behind them when something breaks.

Filed did not need a headcount babysitting broken pipelines. They needed a foundation with schema evolution built in, deployed on their own Azure environment, by a team that had built this exact funnel before.

What Vero Built?

The architecture runs on one constraint: every source lands in one warehouse automatically, and a product deploy should never break a downstream report.

  • Fivetran runs low maintenance managed connectors for all marketing and analytics sources
  • dlt connects Postgres and HubSpot with schema evolution, so new columns never break a report again
  • Snowflake is the central warehouse, queryable by any tool the team already uses
  • dbt builds the Lead to Cash model, joining ad spend through HubSpot deal stages to active, billing workspaces
  • Dagster on Azure AKS orchestrates every pipeline with retries, and automated Slack alerts fire when ad spend per MQL crosses decision thresholds

Every metric now has one definition, whether marketing pulls it, product pulls it, or finance pulls it.

How the Rollout Happened?

The engagement moved in three stages.

  1. Discovery: mapped all 12 systems, defined what a qualified trial actually looks like, and agreed on the Lead to Cash stages the company needed to trust
  2. Warehouse setup: Fivetran and dlt stood up and validated, with schema evolution tested against a live Postgres deploy before launch
  3. Dashboards live: dbt models built incrementally, starting with Lead to Cash, then expanding into trial health, billing, and the adspend alert

Infrastructure was live within days. Dashboards followed as Lead to Cash, trial health, and the ad spend alert came online one after another.

What Changed for the Team?

  • Reporting runs on its own now. Product releases no longer break it, and the team acts on numbers instead of double-checking them
  • Ad spend polices itself. An alert fires the moment cost per MQL crosses $100, catching overspend the same day
  • Decisions run on today's data. CRM refreshes every 30 minutes, product data every hour
  • Manual reporting effort dropped to zero
  • Idle trials are now visible by name, with engagement score and credit usage, so AMs reach out before a trial expires
Solutions designed with your goals in mind
Company Overview
A product-led AI tax platform where prospects enter through ads, organic, and referrals, start free trials, and convert to paying workspaces. The company manages both a marketing funnel and a product trial base simultaneously across 12 data systems.
Arrow to the top of the page button