Custom machine learning and NLP models, trained on your data and tested before launch

What matters is how many examples of the outcome you have, not the total number of rows. A churn model needs enough past cancellations with the customer history leading up to them. A demand forecast needs at least two full seasonal cycles per product group, and a fraud model needs confirmed fraud cases, not only suspicious ones. We assess this during the data audit and tell you whether to start now, collect more data or begin with a simpler method.

Use custom machine learning when you have structured historical data and a clear outcome to predict, such as churn, demand, risk or a category. For these tasks a trained model is faster and much cheaper per prediction than a language model, and on tabular data it is frequently more accurate, which we confirm by testing both on your records. LLMs are stronger at open-ended text, drafting and reasoning over documents. Many systems combine both, for example a language model extracting fields from emails and a classifier scoring the result.

We measure it on data the model has never seen, against a baseline and a metric chosen for the business decision. For a forecast that might be error by product and week compared with your current method. For fraud or churn it is how many real cases are caught against how many false alarms reviewers must handle. We test on a later time period than training to mimic real use, and agree an acceptance threshold before launch.

We build text classification, entity and field extraction, sentiment and intent detection, topic grouping, duplicate detection and search ranking. Typical inputs are support tickets, emails, chat transcripts, reviews, survey answers and contracts. Depending on volume, language and accuracy needs, we use classical models, fine-tuned open transformer models from Hugging Face or a hosted language model, each evaluated on a labelled sample of your own text.

Most supervised models need labelled data, and yes, we can help create it. Labels often already exist in your systems, such as ticket categories, cancellation dates or approved and rejected claims. Where they do not, we write a labelling guide, set up a simple annotation workflow and add a review step so your domain experts label a focused sample. Later rounds go faster because the model suggests labels for people to confirm.

Yes, and for decisions that affect customers or money we treat explanation as a requirement. Each prediction comes with its main contributing factors, for example a recent drop in usage or late payments behind a churn score, alongside overall feature importance for the model. Where the accuracy difference is small we also prefer simpler, more interpretable models, because a prediction people understand is far more likely to be used.

We deploy the model either as a versioned API, usually a FastAPI service in a Docker container, or as a scheduled batch job that writes scores into your database. Your CRM, ERP or application then shows the prediction where users already work. Inputs are validated, every prediction is logged with the model version, and the deployment can run in your own AWS, Azure or Google Cloud account.

A feasibility model for one well-defined prediction typically takes a few weeks after discovery, provided the data can already be exported. The main drivers are data readiness, the number of sources to join and how predictions will be used. The feasibility result tells you whether a full build is worthwhile. Production integration, monitoring and retraining follow in further phases, with working results to review every one to two weeks throughout.

Cost depends on scope, and the largest driver is usually data preparation rather than model training. Model complexity, the systems to integrate and how often predictions must run also matter. After a discovery call we send a written proposal, usually recommending a fixed-price feasibility phase first so you see real accuracy on your data before committing to production. Once scope is agreed we give a fixed quote for the build and an estimate of ongoing hosting and retraining costs.

You do. Training code, feature pipelines, trained model files, evaluation reports and documentation are delivered into your repositories and cloud accounts. We do not use your data to train models for other clients. If you later bring the work in-house, your team has everything needed to retrain, test and redeploy the model without depending on us.

We use only the fields a model genuinely needs, pseudonymise identifiers where possible and keep training data inside your chosen cloud region with access limited to named engineers. For UK clients we design with UK GDPR in mind, including retention rules and the ability to exclude a person's records from future training runs. We work within your compliance requirements, and your legal adviser confirms specific obligations.

Yes. We start by reviewing the existing code, data, validation method and metrics, because underperforming models often suffer from data leakage, an unrealistic test split or features that are not available at prediction time, rather than the wrong algorithm. We then recommend fixes, retrain and compare against your current version on the same held-out data, and either productionise the improved model or hand the changes back to your team.