We build forecasting and prediction models, churn, demand, revenue, lifetime value, on your own data, and then we wire the output into the system where someone acts on it. Every engagement starts by testing whether a simple method already does the job, because often it does, and you should know that before you pay for a model.
No per-prediction pricing · Ranges, not point estimates · You own the model and the code
The shaded band is the range we're actually confident about. It widens the further out it goes, on purpose, every competitor draws one confident line instead.
Illustrative shape, not a client result.
Trusted by teams in the US, UK, and India
Siddhraj
Unoloft
Kofeko
3nStar
Veda
Cerata
Shubham
Consultup IndiaSiddhrajUnoloftKofeko3nStarVedaCerataShubhamConsultup IndiaMost failed prediction projects were doomed before the modelling started. Three conditions, in order.
A model learns from repetition, so the useful question isn't how many rows you have, it's how many times the thing you're predicting has already happened. Ten thousand customers with forty churn events is a thin dataset. Four hundred customers with two hundred churn events is a workable one. For anything seasonal, you need at least two full cycles and preferably three, because with one year of history a model cannot distinguish “December is busy” from “last December was busy.”
If you don't have it yet: the answer is usually instrumentation, not modelling, start recording the outcome properly now so this conversation is possible in a year.
Not in four systems that disagree, not in exports someone rebuilds on Mondays. Modelling on ad-hoc extracts produces a result that can't be reproduced next quarter, which means it can't be trusted and won't be maintained.
If you don't have it yet: that's data warehousing and ETL, and it's the honest first project. We'd rather build you the foundation and revisit prediction in six months than model on sand and hand you a number you can't defend.
This is the one that kills the most projects, and it has nothing to do with data. Before we build anything we ask: when the prediction says a customer is likely to churn, what specifically happens? If the answer is “we'd look at it,” the model will be accurate, admired, and ignored.
If you don't have it yet: define the action first. Sometimes the action turns out to be worth building on its own and the prediction becomes optional.
Every engagement starts with a baseline, a deliberately simple method. Last year's number plus growth. A three-month moving average. A rule your ops lead already uses in their head.
Then we measure it, and the model has to beat it by enough to justify what it costs to build and run. If it doesn't, we tell you, and you don't buy the model. This is standard practice among people who do this work seriously and it is almost never offered by people selling it.
Roughly one in three companies who ask us for a forecasting model should buy a moving average and a dashboard instead. We'd rather be the ones who said so.
Typical trigger: Retention has slipped and nobody can tell whether it's onboarding, pricing, or a single cohort.
Which accounts or subscribers are likely to leave, and which signals are driving it. The output lands in your CRM as a scored field with the top contributing factors attached, so the person making the save call knows why, not just that a number is high.
Typical trigger: You're overstocked and out of stock at the same time, in different SKUs.
Expected demand by SKU and location, with seasonality, promotions, and lead times accounted for, expressed as a range rather than a single number. Feeds purchasing decisions and safety-stock levels.
Typical trigger: A board or lender wants a number you can defend the method behind.
Forward revenue from your actual pipeline and billing history, with confidence intervals, rather than a spreadsheet built on stage-weighted guesswork. For services businesses, capacity and utilisation forecasting alongside it.
Typical trigger: Paid acquisition is scaling and margin isn't.
Predicted value by segment, channel, and acquisition source, which changes what you're willing to pay to acquire. Blended CAC hides the segments losing money; predicted LTV surfaces them.
Typical trigger: Sales says the leads are bad, marketing says sales doesn't work them. Both have a point and nobody has evidence.
Which inbound leads resemble the ones that closed, scored on your own history rather than a vendor's generic model. Written back into the CRM so routing and prioritisation happen automatically.
Typical trigger: Something went wrong and nobody noticed for a month.
Transactions, usage, or operational metrics that don't fit the pattern, flagged in real time with a tuned threshold, because a detector that cries wolf gets muted within a fortnight and then it may as well not exist.
Forecasting demand is this page. Getting the resulting purchase order raised, approved, and synced across channels is inventory management. Writing a churn score into HubSpot and triggering the play is CRM automation. We build across the boundary, the point is that they're separately scoped, so you can see what each part costs.
Notice that none of these is "the model wasn't accurate enough." Accuracy is rarely what goes wrong.
A model flags accounts likely to churn ninety days out. Nobody owns the save motion, there's no play to run, and the list arrives in an email. The model is right and nothing changes, which, after two quarters, is indistinguishable from being wrong.
The decision that prevents it: we define the action before the model. What happens, who does it, and in which system. If we can't answer that in the first call, we say so rather than taking the project.
The model said 0.87 and a manager asked why. Nobody could answer. In anything touching customers, credit, or pricing, an unexplainable score doesn't get used, and in regulated contexts it can't be.
The decision that prevents it: contributing factors surfaced with every prediction, and a preference for interpretable methods unless the accuracy gain from a complex one is large and clearly worth it. Usually it isn't.
The model was validated by testing it on data that included information from after the moment of prediction. It scored beautifully and collapsed in production. This is leakage, it's the most common serious mistake in the field, and it is embarrassingly easy to make.
The decision that prevents it: time-based validation only. We test on a period the model has never seen, in the order events actually occurred, and we report performance the way you'll experience it in production rather than the way it looks best.
It was trained before a pricing change, a new channel, or a supply shock. It kept producing confident numbers based on a world that no longer exists, and nobody was watching the error rate.
The decision that prevents it: monitoring on the predictions themselves, not just the pipeline. We track error against reality as outcomes arrive, alert on drift, and retrain on a schedule. This is the part that isn't a project, it's why the monthly plan exists.
The forecast said 4,200 units. Someone ordered 4,200 units. The honest answer was somewhere between 3,400 and 5,100, and the decision that should have been made, how much safety stock to carry, was never surfaced because the interval got flattened into a point.
The decision that prevents it: every forecast ships as a range with a stated confidence level, and every interface we build displays the range. A point estimate is a summary of a distribution, and the distribution is the part you make decisions with.
Four of these five are decisions made before any modelling starts. None of them are about which algorithm you picked.
That's usually settled in one call. Tell us what you want to predict and how long you've been recording it, and we'll tell you whether it's workable, what the baseline would be, and whether a model is likely to beat it, before you commit anything.
Book a 30-minute callEvery result is shown against the simple method it has to beat. If the gap is small, that's in the report, in writing, where you can see it.
Trained on the past, tested on the future, never the reverse. The accuracy number we give you is the one you'll live with, not the flattering one.
Every forecast carries an interval and every interface we build shows it. The width of that band is often more useful than the estimate inside it.
Into the CRM field, the purchasing screen, the Slack alert. Not into a slide deck and not into a notebook only an analyst can open.
Training code, features, weights, and documentation transfer on final payment. No black box, no per-prediction pricing, no platform you can't leave.
Predictions are compared against what actually happened, continuously. Accuracy decay is normal and expected, going unnoticed is what makes it expensive.
Since 2023 the vocabulary has collapsed, and it costs people real money. A significant share of the projects we're asked to quote are described in the wrong category entirely.
It learns from your historical records and estimates a quantity or a probability, units, revenue, likelihood of churn. It's trained on your data, it can be measured against reality, and you can state exactly how wrong it usually is. This page.
It's a large model trained on text, prompted rather than fitted, and useful for reading, writing, summarising, and answering. Its correctness is judged, not measured. That's generative AI and custom LLMs.
The practical test: if the right answer is a number you could eventually check against what happened, it's predictive. If the right answer is a piece of text a person has to read and judge, it's generative.
They're built differently, they cost differently, and they fail differently, a forecast drifts quietly, an LLM makes something up confidently. Plenty of systems use both: a model predicts which accounts are at risk, an LLM drafts the outreach. But scoping them as one project is how budgets get spent on the wrong half of the problem.
What are we predicting, who acts on it, in which system, and what does being wrong cost in each direction? Under-forecasting and over-forecasting rarely hurt equally, and that asymmetry shapes the whole model.
We assemble the history, check it's sufficient, and build the simple method. You get a written baseline number. Everything afterwards is measured against it.
We build a first model and compare it to the baseline honestly. If the improvement doesn't justify the cost of building and running it, we say so and the engagement stops here. You keep the baseline, the data work, and the write-up. This is a real exit, not a formality, and it's the reason the earlier phases are priced separately.
The model, the retraining pipeline, monitoring on prediction error, and the integration that puts the output in front of the person who acts on it.
Error tracked against outcomes as they arrive, drift alerting, scheduled retraining, and a named engineer. Models decay, that's the nature of the technology, not a defect, and it's scoped from day one.
You want to know what's likely to happen next, and act on it.
You want to know what happened and what's true now.
You want one screen answering a known set of questions.
Your data isn't in one place yet, and it's the honest first step.
You want something written, read, or summarised.
You want something to happen automatically when a threshold is crossed.
If you're not sure, the discovery call sorts it in twenty minutes and we'd rather route you correctly than sell you the wrong scope.
Fixed price, quoted in writing before we start. The first step is deliberately small.
Two weeks. Data assessment, the baseline method, a written verdict on whether a model is likely to beat it, and by how much. You can stop here and many should. Deducted from the build price if you continue.
$249
Good for: anyone who hasn't built a prediction model with us before, almost everyone starts here.
The model, validation, retraining pipeline, monitoring, and integration into the system where the decision happens. Fixed scope, fixed price, typically starting two to four weeks after feasibility.
Priced after the feasibility phase
Good for: a feasibility phase that cleared the bar and a decision worth wiring the output into.
Error monitoring against actual outcomes, drift alerting, scheduled retraining, threshold tuning, and a named engineer. Available on models we built and on models we didn't.
A monthly plan sized to your model
Good for: any model in production, ours or someone else's, models decay and most clients end up here.
We've built the data foundations underneath prediction work, pipelines, warehouses, and the reporting layer, and you can see that work in Unified Accounting and PartsFlow.
Neither is a forecasting project, and we're not going to present them as one. Predictive analytics is a newer part of our practice than our automation and data engineering work.
What that means for you, practically: the feasibility phase exists partly so you can judge us on your own problem before committing to a build. Two weeks, a fixed price, a written verdict, and a real exit. It's a shorter and cheaper way to assess a vendor than reading a case study about somebody else's business.
Book a 30-minute call. We'll tell you whether your data can support a prediction, what the simple version would look like, and whether a model is worth building at all.
