Build if you have engineers and analysts to spare, clean history, and a reason to own the model. Buy if you want a daily list for your team without carrying a data science project. The model itself is the small part of either choice. Most of the effort goes into the data layer, validation, and getting scores into a form your team will use. I sell a product, so weigh my view accordingly. I have tried to describe the build honestly, including the parts that make it expensive.
What does building involve?
Five layers, from the bottom up: source data, an adapter that reads it, a feature pipeline, a scoring layer and a delivery layer that puts scored lists in front of the team. The engineering notes I wrote on per-player scoring architecture go through them in more detail. In short, scoring is 90 percent substrate and 10 percent model, in the words of that guide.
For a mid-size operator, the write-ups I link put a first deployment at roughly six to twelve weeks, depending on the state of the source data and how custom the platform is. They also describe a two-phase approach: a data audit and adapter first, then models and a pilot. If the data is not ready after the first phase, stopping is a good outcome.
Where does the time go?
Mostly into things that are not machine learning:
- The adapter. Which table has transactions, which field means what, whether amounts are in cents or whole units, whether times are UTC or local. For self-written platforms, which are common, this takes a large share of the effort.
- Account types. Test, service and bot accounts must be filtered out before training.
- Feature timing. Features must be computed from raw transactions as of the scoring moment. Pre-aggregated platform statistics can leak information from the future and make the model look good offline and fail live.
- Validation. Time-aware splits, calibration, and a shadow period of about two weeks before the team acts.
- Delivery. A ranked worklist with reasons, in the tool your team already opens.
None of these is glamorous. All of them decide whether the system is used.
Which model do you need?
A gradient boosting model on tabular features is a sensible default. It is fast, small and its decisions can be explained with SHAP values an analyst can read. You want two models, not one: the probability that an active player leaves soon, and the probability that a player who has gone quiet returns. They lead to different actions.
I would keep language models out of anything that touches money. Their output is hard to audit, and a wrong score costs real bonus budget before anyone sees it. They have a place in drafting message copy or summarising a player's history for a manager, where a human reviews the output.
What does it cost to keep running?
More than the first build suggests. Player behaviour drifts as products, markets and player mixes change, so the model needs retraining, weekly on a rolling window as a default and monthly at the outside. The retraining must reuse the same feature pipeline as scoring, or training and production will quietly diverge. Someone has to monitor drift, version the models and fix the adapter when the platform changes.
That is a standing responsibility for a person or a small team. If you have no one for it, the model will decay, and your team will stop trusting the list.
Remember also the cost of what you do not build. A scoring system alone is not yet a retention process. Somebody has to choose offers, handle the channels, check consent and review the results. If you build the model, plan for the worklist, the reasons shown to the team and the measurement as well, or you will own an accurate forecast that nobody acts on.
When does building make sense?
- You have data engineers and an analyst with time, and the work is a priority.
- You have more than six months of reliable, clean history.
- You want the model, the features and the data to be fully your own.
- Your needs are unusual enough that a standard product would not fit.
In that case, build, and use the shadow period and a control group to check what you made.
When does buying make sense?
- You want a daily list soon, without a data science project.
- Your team is small, or your ARPU is thin, and a standing analytics team does not fit the budget. See casino retention when a player is worth a few dollars.
- You want forecasts for churn, VIP potential, next deposit and 90-day value from one place, with the operator queue and bonus matching on top.
With Sellrise, you provide four tables keyed by Player ID, integration is at our cost, and each client has a separate database. Your team sees a daily list with a reason, priority, channel, time and offer for each player. The cost and pricing logic are in how casino CRM is priced.
How do you decide with evidence?
Run the same test for either path. Take a control group that nobody contacts, a group handled as today and a group handled by the forecasts, and compare average turnover per player after a month. For a purchase this is a pilot. For a build it is the milestone that decides whether the project gets a second quarter. The plan is in how to run a control group test.
The questions to put to a vendor are collected in how to choose casino retention software. If you want to try ours, open the demo or start a pilot.