Services / AI features
AI where it actually helps.
Putting a language model behind a real workflow: reading documents, extracting structure, drafting text a person then approves.
- Best for
- Businesses with a repetitive reading or writing task that a person currently does by hand.
- What it costs
- Fixed price against a written scope. Model usage is billed to your own provider account, so you can see what it costs and it does not run through me.
- How it runs
- A narrow first version is usually two to three weeks, because most of the time goes on the boring half: what happens when the model is wrong.
01 / Summary
The short version
The useful applications are narrower than the marketing suggests, and they nearly all have the same shape: something arrives as messy text, and a person currently reads it and types a structured version somewhere else. Invoices, enquiry forms, reviews, applications, support tickets.
I work with language models every day. Context Mesh, one of the projects on this site, is a tool I built to make AI coding assistants cheaper and more accurate, and its savings are measured by a repeatable test instead of claimed. The same habit applies to your workflow: a defined job, a measured error rate, and a cost you can see.
One thing I will gently question: a chatbot on your homepage often does less for visitors than a good search box and a clear price list. If that is the brief, I will suggest the simpler option first so you can compare.
02 / Deliverables
What you get
- 01A defined task with measurable output, rather than a general assistant
- 02Extraction into your existing database or spreadsheet, in the shape you already use
- 03A human approval step wherever being wrong has a cost
- 04Fallback behaviour for when the model returns nonsense, because it sometimes will
- 05Usage and spend visible in your own provider account from day one
- 06Tests over the extraction paths, so a prompt change cannot quietly break last month's behaviour
03 / Process
How it runs
- Step 01
Task
We pick one job that a person does repeatedly, and write down what a correct answer looks like.
- Step 02
Trial
A small run over your real examples. You see the failure rate before committing to a build.
- Step 03
Build
The working version, wired into where the data already lives, with the approval step in place.
- Step 04
Hand over
Your provider account, your keys, your data. It keeps running without me.
05 / Questions
Common questions
01What does it cost to run?
Model usage is billed to your own account, and for extraction work at small business volumes it is usually a very small monthly figure. The trial run in step two gives you a real per-item cost before you commit, which is more useful than an estimate from me.
02What if it gets things wrong?
It will, sometimes. That is why anything with a real cost attached gets a person approving it before it takes effect. The design question is never whether the model is perfect, it is what happens on the occasions it is not, and that gets decided before the build rather than after the first bad week.
03Is our data used to train anything?
Not under the standard business API terms of the major providers, and the account is yours so you can read the terms rather than take my word for it. If the data is sensitive enough that this matters, let me know early and it changes which options are on the table.
04Do we need this at all?
Often, no. If the task happens twice a month, a person doing it by hand is cheaper than anything I would build. The threshold is roughly when the reading is frequent enough to be somebody's actual job.
