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.
AI
Machine learning in production.
Models that run in production: features you can recompute, an offline metric tied to a business one, monitoring for drift, and an honest answer about when a rule is enough.
What this looks like on a real project
-
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.
Discuss the next step
Tell us what you want to build or improve. We reply with a plan, an indicative budget and a start date.