With enough time, you could build what we built. Here's how.
Our build spec, the mistakes we made along the way, and how to size the project. (But if you'd rather spend that time on your own GTM projects, how to build them with Fluint context.)
Stage models, retraining and drift checks18-32 wks
Time-series store with backfill16-30 wks
ETL and entity resolution10-16 wks
01The build spec
Everything you need to build, with our estimates.
These are the pieces we had to build, grouped the way we built them. Effort is in engineer-weeks for a team that has done this kind of work before.
REQUIREMENTDIFFICULTYEFFORTWHOWITH FLUINT
DATA IN
Connectors for CRM, calls, email and warehouse
Read every source on a schedule and handle API limits, schema changes and deleted records.
Straightforward6-10 wksData engineerWe run it
Entity resolution across systems
Match the same person, account and deal across tools that each use their own IDs.
Moderate4-6 wksData engineerWe run it
TIME-SERIES STORE
Object briefs
A labeled summary for every deal, account, contact and meeting, rebuilt when its inputs change.
Moderate4-8 wksData + ML engineerWe run it
Point-in-time snapshots
Write each change with a timestamp so you can see any object exactly as it was on any past date.
Hard6-10 wksData engineerWe run it
Backfill when a definition changes
When a stage, field or predictor changes, rebuild every past snapshot so old and new labels stay consistent.
Hard6-12 wksData engineerWe run it
MODELS
A model for each sales stage
XGBoost, KNN and time-series models, each suited to the question that stage asks.
Hard8-14 wksML engineerWe run it
Causal lift, controlled for deal mix
Separate what drives wins from what simply shows up in won deals.
Very hard6-10 wksData scientistWe run it
Retraining and drift checks
Retrain as deals close, compare each version, and roll back when accuracy drops.
Hard4-8 wksML engineerWe run it
SERVING
Findings turned into plays
Write each finding as a step a rep can take, with the expected lift attached.
Moderate4-6 wksRevOps + engineerWe run it
Pre-built context over MCP
Compute context when the data changes and serve it ready, with citations, to any agent.
Straightforward2-4 wksEngineerWe run it
YOUR PROJECTS
Agents, scoring, routing, forecasts
The tools your reps and leaders actually use.
DependsVariesYour teamYou build
Total to a first working model50-88 wksthen 1-2 engineers ongoing
02How we built it
We built it as a loop that retrains itself.
Connect Loop from Fluint once. It captures every object, snapshots it over time, and studies the trajectory to model what wins, with ready-to-ship agents to do more of it. With every outcome flowing back in and retraining your private models.
1
Capture, a brief for every GTM object: deals, accounts, contacts, meetings.
2
Snapshot, each brief captured through time, so we can model what changed and when.
3
Model, measure how much each behavior actually lifts win rate.
4
Serve, the play plus pre-materialized context, over one MCP call.
5
Act: agents and reps run it, and outcomes return to step 1.
Every closed deal retrains the ensemble. The model compounds; dashboards age.
03Object briefs & snapshots
A brief for every object, snapshotted through time.
Fluint builds a structured brief for every object in your GTM data. Each brief is a labeled summary of that object's dimensions, features, and the predictors attached to it: what the object was at a given moment, with the history of how it got there.
We snapshot every brief across the whole dataset. Each time a predictor or dimension changes, the new state is written with its timestamp, so the model sees what changed and when, across the full history of the deal.
RECOMPILE & BACKFILL
On each change, briefs are recreated and backfilled across history, recompiling the entire historical graph point-in-time. The label existed at the right moment, with no leakage, which is what lets the ML layer establish a causal relationship it can defend.
brief.snapshotpoint-in-time · backfilled on change
brief.snapshot { -- one row per object, per change
ts timestamptz-- when this state became true
object deal | account | contact | meeting | ...
object_id string
dimensions json-- stage, segment, owner, ARR band
predictors json-- { cfo_attended: true, multi_threaded: false }
outcome_ref string?-- joined at close
}
on_change(predictor) → recreate(brief) ; backfill(history) ; recompile(graph)
Entity resolution across systemsBackfilled & recompiled on every changePoint-in-time correctness (no leakage)Labels versioned with the schema
04A model per stage
Causal lift you can defend.
Because your data store is built in a time series structure, you're able to run a regression to attribute outcomes to their causal drivers, controlling for everything else moving in a deal. Each stage asks a different question, so we let you run a model suited to it, all deployed and monitored for you. Select a stage for examples:
XGBoost + Time-series
Predictor lift + trajectory
Boosted trees rank behavior lift; a time-series model watches the deal's shape vs. healthy cohorts.
INPUTS
Multi-threading, exec attendance, event timing
PREDICTS
Win-rate lift per behavior, and drift
FEEDS
The #1 predictor and the play that closes it
Provisioned for you
We stand up and maintain the time-series store, the feature pipelines, and the training jobs. No infrastructure for your team to run.
Retrained and monitored
Models retrain on a schedule as deals close. We watch every version for drift and accuracy, and roll back automatically when a release underperforms.
Turned into a play
Each finding is translated into a plain-language play a rep and a sales leader can act on today, with the projected lift attached.
SCIENCEtoACTIONThe model proves the lift; the play is what a rep runs on Monday. Both live in the same context call.
05Mistakes we made
What we got wrong the first time.
Most of these looked fine in testing and only showed up once real deals ran through the models. If you build it yourself, plan for them from the start.
01
We trained on today's CRM values.
Stage and amount fields get overwritten as deals move. A model trained on current values learns from the ending, so it tests well and fails on open deals.
FIX Snapshot every change and train on what was true at the time.
02
We read correlation as cause.
Won deals have more meetings because they were already going well. Treating meeting count as a predictor sent reps chasing the wrong thing.
FIX Control for stage, segment and deal size before calling anything a predictor.
03
We changed a definition and didn't backfill.
RevOps renamed a stage mid-quarter. Old and new labels mixed in the training data and accuracy slipped for weeks before we caught it.
FIX Rebuild every past snapshot whenever a definition changes.
04
We didn't watch for drift.
A pricing change shifted what wins in one segment. The model kept scoring the old pattern with full confidence.
FIX Compare each retrain against the last and alert on drops in accuracy.
05
We shipped findings nobody used.
Reps and managers read a coefficient table once. Nothing changed on their deals.
FIX Turn each finding into a play with a clear next step and expected lift.
06
We built context on every request.
Assembling context when an agent asked for it was slow and burned tokens on every call.
FIX Compute context when the data changes and serve it ready.
06Size your project
How big is this for your team?
Move the inputs to match your setup. The ranges come from the spec above.
TIME TO A FIRST WORKING MODEL
7-11 months
BUILD COST
$239K-$421K
UPKEEP PER YEAR
$253K
Assumes $220K a year per engineer, fully loaded. Upkeep covers retraining, drift checks, schema changes and new sources: about 1.1 engineers.
07Build, buy, or both
Three ways to get there.
Most teams we talk to want to own the projects their reps and leaders see, and would rather not own the pipeline underneath.
BUILD IT ALL
Build it yourself
Your team owns every row of the spec, from ETL to serving.
TIME Months to a first model, then 1-2 engineers to keep it running.
BEST FOR Teams with data and ML engineers who have the time and want full control.
RECOMMENDEDBUILD WITH FLUINT
Build on Fluint context
We provision and maintain the store, models, drift checks and context. Your engineers build the agents and workflows on top.
TIME First context call in one session. Engineering time goes to your projects.
BEST FOR GTM engineers who want their own tools without owning the pipeline.
BUY IT ALL
Use Fluint as it comes
Predictors, plays and proactive agents, ready for reps and leaders.
TIME Live in days, with no engineering time.
BEST FOR Teams that need results before they have engineers to spare.
08Build with Fluint
Build your projects on context that is already proven.
Everything in the spec above sits behind one MCP tool. Add Fluint to any agent framework and spend your engineering time on the projects themselves. It returns conclusions your agent can act on: predictors, active plays, and the evidence behind them, already computed. The same call works from Claude, ChatGPT, Copilot, or your own agent.