What SpiderHunts Brings to Your Business With Machine Learning
Last updated:
A model is the smallest thing we hand over
Most businesses that approach us about machine learning think they are buying a model. A file that predicts churn, or demand, or which invoices are likely to be paid late. That file matters, but on a typical project it is perhaps a fifth of the work and a smaller share of the value.
The rest is everything that makes a prediction useful on an ordinary Wednesday: the cleaned data it depends on, the place in your software where the score appears, the rule for what a person does when they see it, and the alert that fires when the model quietly stops being right. A model without those is a demo. We have been asked to rescue enough demos to know what they cost.
A straight answer on whether machine learning fits at all
The first thing we bring is a verdict, and sometimes it is no. A surprising number of prediction problems are better served by a handful of business rules, a well-built report or a better form that captures the data properly in the first place. Our write-up on machine learning versus a rules engine covers the reasoning in more depth.
We look for three conditions before recommending a model:
- A decision that repeats often enough for small improvements to add up, such as pricing hundreds of quotes a week rather than five a month
- Historical data where the outcome of each case was recorded alongside the inputs
- Someone who will act differently because of the prediction, with the authority to do so
- A cost of being wrong that is tolerable while the model earns trust
If the second condition fails, the honest first project is usually collecting the outcome data properly for six months. That is less exciting to sell and far more useful to buy.
A baseline you can argue with
Before any modelling, we measure how the decision is made today and how good it is. A wholesaler forecasting stock by taking last year's figure and adding ten percent has a baseline. So does a sales team that marks leads hot or cold by feel. We write that number down and agree it with you.
This sounds like bureaucracy. It is the single most useful protection a buyer has. Without a baseline, any model looks impressive, because there is nothing to compare it with. With one, a model that beats the current method by a small margin gets a sober conversation about whether that margin pays for the build and the upkeep.
An accuracy figure without a baseline is a number looking for a compliment.
The model, wired into a decision someone makes
Our machine learning development work ends inside the software your team already opens. A churn score appears on the account screen in the CRM. A forecast lands in the purchasing spreadsheet the buyer already uses. A risk flag routes an application to a senior reviewer instead of the standard queue.
We design that placement with the people who will use it. A 20-person insurance broker, for example, does not need a dashboard of probabilities. It needs the three renewals most likely to lapse this week at the top of someone's task list, with the two reasons that drove each score. Getting that right is often the difference between a model that is used and one that is admired once and ignored.
What you own at the end
Everything built on the project belongs to you from the first commit, and it is structured so another competent team could pick it up. On a typical engagement that includes:
| What you receive | What it is | Why it matters later |
|---|---|---|
| Data audit | A written account of what the data can and cannot support | Stops the next idea repeating the same dead end |
| Feature and training pipeline | Code that rebuilds the training data from source | Retraining is a command, not an archaeology project |
| The model and its evaluation | Model plus results against the agreed baseline | You can see what improved and by how much |
| Integration code | The API or job that puts scores into your systems | The model stays connected when systems change |
| Monitoring and alerts | Drift checks and performance tracking | You find out it degraded before customers do |
| Runbook and handover | How to retrain, redeploy and roll back | Your team is not dependent on us |
What we do not bring
We do not bring knowledge of your customers, your suppliers or why the March figures always look odd. You do. Every project we have seen go well had someone on the client side who could say, within a day, whether a pattern the data showed was real or an artefact of how something was recorded.
We also do not bring guarantees about accuracy before we have seen the data. Anyone quoting a precision figure on a first call is guessing. What we can commit to is a clear go or no-go point after the data audit and a first model, so you are never several months into a project that was never going to work.
Is it worth it for a business your size?
Machine learning pays off when a decision is frequent, the data exists and a modest improvement is worth real money. It rarely pays off for a business making a handful of large decisions a year, where an experienced person with a good report will do as well.
- Count how often the decision happens each month
- Estimate what a better decision is worth each time, even roughly
- Check whether the outcome of past decisions was recorded anywhere
- Name the person who would act on a prediction
If those four answers are strong, a conversation with SpiderHunts is worth half an hour. If they are weak, we would rather tell you now than after a proposal.
Frequently asked questions
How much historical data do we need for machine learning?
Can we start with a small machine learning project?
Do you use our data to train models for other clients?
What happens if the model stops working after launch?
Is an LLM a replacement for a custom model?
Wondering whether your data could predict something useful?
Describe the decision you want to improve and what data you already hold. We will tell you plainly whether machine learning fits, before anyone talks about a model.