Custom AI is worth building only when nobody sells a tool that does your job.
Reading a supplier’s invoice is a solved problem. Reading the particular invoice your Hubli supplier sends, where the item code is in the remarks column and the quantity is in dozens, is not. Nobody sells that, because there is a market of one.
That is the gap this work fills. A model doing a narrow job that is specific to how your business runs, wrapped in software that handles everything around it.
Custom AI software is an ordinary application with a model inside it, doing one task that a person does by hand today. Grading a photograph of a casting, pulling fields out of a form only your industry uses, sorting enquiries into categories you invented. The model is a component. Most of the build is the software around it.
Where it earns its place.
The test before we build anything
Five questions. A no on any of them and we say so rather than quote for it.
- Is there a product that already does this well enough
- Can the job be described precisely enough to judge an answer
- Do you have examples of the work done correctly in the past
- Can a wrong answer be caught before it costs something
- Is the running cost smaller than the work it removes
Jobs that pass it
The shape is always the same. A person reading, sorting or copying, many times a day, with a right answer somebody could confirm.
- Fields lifted from a form peculiar to your trade
- Purchase orders arriving as photographs in a WhatsApp group
- Messy supplier names matched to one master record
- A first draft of a quotation the estimator then corrects
- Photographs checked for a defect before dispatch
What the build is mostly made of
Under a tenth of it is the model. The rest is what makes the answer usable.
- Define the job
- Gather examples
- Build
- Evaluate
- Review step
- Deploy
- Getting the document or image in, whatever state it arrives in
- A screen where a person confirms or corrects the answer
- The confidence threshold below which nothing goes through
- Writing the result into the system that already holds the record
How we know it works
This is the difference between a demo and something you can run the business on.
- A set of real past cases with the correct answer already known
- The system scored against that set before and after every change
- Errors kept and grouped, so the pattern is visible
- A number you can watch, such as how many still need correcting
We will not tell you what accuracy it will reach before we have seen your data. Anyone who does is guessing.
Rules are often the better answer
A model is the right tool when the input is messy and the output is a judgement. It is the wrong tool when the answer is a calculation.
- GST on an invoice is arithmetic, not a judgement
- A credit limit check is a rule somebody wrote down
Rules are exact and cheap to run. Where one fits, we build the rule and leave the model out of it.
When this is the right choice.
- A person reads or retypes the same kind of document many times a day
- The input is messy in a way no product has bothered to handle
- You have a pile of past examples showing the correct answer
- Being right most of the time, with a person catching the rest, is genuinely useful
- The output has to land inside software you already run
When it is not.
- A job an off-the-shelf tool already does acceptably, where building is vanity
- Work with no examples of past answers, since there is then no way to know it works
- Anything that is a rule or a calculation, which should be written as one and will be exact
- An answer that reaches a customer with nobody in between, where being mostly right is not a standard
- A process that changes every few months, because the examples go stale faster than you can gather them
Questions we are asked about it.
Should we build this or buy a product?
Buy, unless the job is specific to you. We look for an existing product first and will tell you when we find one, even though that ends the conversation. Building makes sense when the peculiarity is the whole problem.
How much of our data do you need?
Enough examples to test against, which is usually less than people expect. A few dozen real cases with known correct answers is a workable starting point for judging whether the approach holds.
Do you train your own models?
Rarely, and only when the job cannot be done otherwise. Most business tasks are better served by a general model given your data and clear instructions. Training is expensive to do and more expensive to keep current.
Will it read handwriting?
Printed and typed documents are reliable. Handwriting varies from good to hopeless, and a delivery challan filled in at a loading bay is usually nearer the second. We test on your worst examples first, not your neatest, so the answer comes early.
What does it cost to run?
There are two parts: the per-use charge from the model provider and the hosting for everything around it. Both depend on volume and on which model the job needs, so we size them during the audit and put the figures in the proposal.
What if it gets things wrong?
It will, and the build is designed around that. Low-confidence cases go to a person instead of through, corrections are captured, and you watch the correction rate rather than trusting a claim made at the start.
Services that use it.
What it sits with.
Not sure Custom AI software is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- We reply the same working day
- Your details stay private