The first question we ask about a machine learning idea is whether a rule would do it. Quite often one would, and saying so costs us a project and saves a client a system they would have to maintain forever.
When a model is the right tool
When the pattern is real but too irregular to write down: churn risk, demand forecasting, ranking, fraud signals, matching, recommendations. Enough history exists to learn from, and being right more often than a heuristic is worth money.
Features are the actual work
Most of the effort is not modelling. It is defining features that can be computed the same way in training and at serving time, from data that will still exist next year. A feature that leaks the answer will look brilliant offline and fail the day it is deployed.
Two metrics, tied together
One offline metric to compare models, one business metric to justify the project. If nobody can say which business number should move, the project has no finish line and we would rather find that out in week one.
Serving and monitoring
The model ships as a versioned artefact behind a defined interface, with the previous version one switch away. In production we watch input distributions, prediction distributions and outcomes, because a model does not crash when the world changes — it just gets quietly worse.
Language models are a different animal
If the problem is text, retrieval and prompting usually get there faster than training anything. That work is described on LLM development, with the delivery view on AI development.
Built in Python, fed by BigQuery, deployed like everything else through CI/CD.