The prediction you were about to build just got a lot cheaper

You have a churn model or a personalization feature somewhere on your roadmap. Someone quoted you weeks of data science work: feature engineering, tuning, retraining. That estimate is now out of date. New tools let you get a solid prediction on your data in one shot, no training run. That does not mean you skip the hard parts. Let me catch you up on what changed and what to bring to your next review.

The model that skips the training run

Google just shipped TabFM, a zero-shot foundation model for tabular data. Plain version: it makes predictions on spreadsheet-style data, the kind behind churn and fraud, without training a fresh model for your dataset. You hand it your table, it returns predictions in a single pass. No hyperparameter tuning, no feature engineering.

The old way meant a data scientist fitting an XGBoost model, which Google notes "is not merely a matter of a single .fit() step" and "invariably requires tedious manual effort." That effort was the cost. TabFM is trained on hundreds of millions of synthetic tables, so it walks in already knowing how columns tend to relate.

And it holds up. Against tuned industry-standard algorithms on the TabArena benchmark, across 38 classification and 13 regression datasets, TabFM matched or beat them. It is landing inside BigQuery as a simple AI.PREDICT SQL command. Someone on your team who knows SQL can run it.

Cheaper to start is not cheaper to run

The upfront cost drops. The system around the prediction does not. The production recommender playbook from Utkarsh Mittal is a good reality check on what still has to exist. Tight latency budgets, around 200 milliseconds. Two-stage architecture, fast retrieval then richer ranking. Feature stores to stop training-serving skew, where the data your model saw in training does not match what it sees live.

The piece names four ways these systems rot: monitoring gaps, popularity spirals, offline-online mismatch, and training-serving skew. None of those go away because your model was easy to spin up. They are operational problems, and they are where your ongoing cost lives.

So the math shifts, but it does not disappear. You save on the build. You still pay for the pipeline, the monitoring, and the people who keep it honest.

The part everyone forgets: it drifts

A model that scored well last quarter can quietly get worse. Not quietly, actually, loudly, if you are watching. Apple's Fortress case study puts numbers on the problem. Engagement features, like clicks, give strong predictive power but introduce temporal instability. The scores for the same item swing across time periods. In a multi-stage system, that wobble compounds downstream.

Apple's fix was to find and prune the features causing the swings, then retrain on the stable ones. Worth flagging to your team: the fancy features are often the unstable ones. More signal is not automatically better if the signal jumps around.

Apple's TopoPrimer work shows where models break hardest. Under peak seasonal demand, classical and zero-shot models degrade by up to 50%. That is your Black Friday, your launch spike, the exact moment you need the prediction to hold. TopoPrimer kept it within 10% and cut cold-start error by 27% when an item had no history.

Buy the model, keep the discipline

Woodside Energy has been running AI in production since around 2015, long before the current wave. Their maintenance intelligence work cut maintenance hours by up to 15% over five years on a piloted asset. The lesson is not the tech. It is what came first. Andrew Melouney, their VP for digital, says the real work was "aligning people, processes, and the technology together," plus years of governed, well-structured data.

His motto: "Think big, prototype small, and scale fast." The prototype gets cheap now. The scaling still rides on clean data and people who trust the output.

One more line from Melouney worth keeping: they design AI to keep the human accountable for the decision. The model gives the recommendation. A person still owns the call. That is a good default when you are handing a fast, easy prediction to a team that did not build it.

The deep cut

The cheap part just got cheaper, so your review should stop debating whether to build the model and start debating whether you can run it. Before you greenlight a custom ML project, ask what it would cost to instead run TabFM or a similar zero-shot model on your data this week, and spend the saved budget on monitoring and feature stability. The build was never the expensive part. Drift, skew, and demand spikes are. Put your money there.

And test the tool where it hurts, not where it is easy. A model that scores well on a calm Tuesday and falls apart 50% at your seasonal peak is worse than no model, because you will trust it right up until it fails you.

Three questions for your team

1. For the next prediction feature on our roadmap, what does a zero-shot model on our existing data cost us to try this quarter, versus the custom build we scoped?
2. If we ship a model, who owns monitoring for drift and training-serving skew, and how would we know within a day that scores went bad?
3. Which of our features are the volatile ones, and would pruning them cost us less accuracy than the instability they add during a demand spike?