AI integration and automation
A language model is very good at a specific class of problem and actively dangerous outside it. The valuable work is not adding AI to your product; it is identifying the two or three places where it beats a rule, and being disciplined about the rest.
Where language models genuinely win
Unstructured input becoming structured output. Extracting line items from a supplier invoice that arrives as a photograph. Routing an inbound email to the right team when the subject line is unreliable. Summarising a long thread for someone who has to make a decision about it. Classifying free-text notes into categories that were never enforced at entry.
These share a shape: the input varies unpredictably, a human currently does it, the cost of an occasional error is low, and the output can be checked. That last condition is the important one — automation is safe in proportion to how cheaply a mistake can be caught.
Where they lose to a rule
Anything with a correct answer that a rule can express. Tax calculation, discount eligibility, credit limits, stock allocation. Using a model for these swaps a deterministic, testable, auditable rule for a probabilistic one that is none of those things, and does it at a higher running cost.
We have turned down this work, and we will say so on a call rather than build something we would not run ourselves. If a rule can express it, a rule should express it.
Building it so it can be trusted
Every model-driven step needs an evaluation set — real examples with known correct answers — before it goes anywhere near production. Without one you cannot tell whether a prompt change improved things or quietly broke a category of input, and you certainly cannot tell after a model version updates underneath you.
Then: a confidence threshold that routes uncertain cases to a person, a full audit log of what was sent and what came back, a cost ceiling per operation, and a fallback path for when the provider has an outage. Retrieval over your own documents rather than fine-tuning, in almost every case — it is cheaper, it can be corrected by editing a source document, and it can cite where an answer came from.
What this actually covers
Document processing
Invoices, purchase orders and forms turned into structured records, with confidence scores and a human review queue.
Retrieval-augmented assistants
Internal question answering grounded in your own documents, with citations, so an answer can be checked.
Classification and routing
Inbound email, tickets and free-text notes sorted reliably, with the uncertain cases escalated rather than guessed.
Workflow automation
The unglamorous majority: connecting systems, eliminating re-keying, and scheduling what a person currently remembers to do.
Evaluation harnesses
A real test set with known answers, so a prompt or model change can be measured instead of guessed at.
Cost and safety controls
Per-operation ceilings, rate limits, audit logging of inputs and outputs, and a fallback for provider outages.
The sequence
Same shape on every engagement, so you always know what week you are in and what happens next.
Sort the candidates
Every proposed use is tested against one question: could a rule do this? If yes, a rule does it. What survives that filter is the shortlist.
Build the evaluation set first
Real examples with known correct answers, assembled before any prompt is written. Without it, every later change is a guess.
Pilot narrowly, with a human in the loop
One task, one team, everything reviewed. Measured against the evaluation set and against the time it actually saves.
Widen only where the numbers hold
Automation expands where accuracy and cost both hold up. Where they do not, we say so and stop rather than quietly lowering the bar.
Handed over, in your accounts
Not a demo and a login. These are the artefacts you keep, and they are what makes leaving us possible.
- A written assessment of which candidate tasks suit a model and which suit a rule
- An evaluation set of real examples with known correct answers, in your repository
- A confidence threshold and a human review queue for anything below it
- Audit logging of every prompt and response, for review and for dispute resolution
- A cost model per operation, with ceilings enforced in code
- A documented fallback path for provider outages and model deprecations
Typically built with
- Claude API
- OpenAI API
- TypeScript
- Python
- PostgreSQL
- pgvector
- Queues
- n8n
The selection principle is deliberately dull: largest hiring pool, longest support window. See why we choose these.
AI & Automation, answered
The things people ask on the first call, written down so you do not have to.
Should we add AI to our product?
Only where it beats the alternative, and the honest answer is often no. The test we apply is whether a rule could produce the same result — if it could, the rule wins, because it is deterministic, testable, auditable and cheaper to run. Where a model genuinely wins is unstructured input becoming structured output: reading varied documents, classifying free text, summarising for a decision. We will tell you which of your candidate ideas fall into which category, including when the answer is that none of them do.
What does it cost to run?
It depends on volume and on how much text moves through each operation, which is why we model cost per operation before building rather than discovering it on the first monthly bill. Two things make the difference in practice: choosing a smaller model for tasks that do not need a larger one, and not re-sending context that could be cached or retrieved. We enforce a ceiling per operation in code, so a runaway loop cannot produce a surprise invoice.
How do you stop it making things up?
Three things, in order of importance. Ground it in your own documents through retrieval so it answers from source material rather than from memory, and make it cite which document. Set a confidence threshold below which the case goes to a person instead of being answered. And maintain an evaluation set of real examples with known answers, so a prompt or model change can be measured rather than assumed. No arrangement removes the risk entirely, which is why we only apply this where a mistake is cheap to catch.
What about our data privacy?
It is a design decision made before anything is built. Enterprise API tiers from the major providers do not train on submitted data and offer regional processing, which covers most cases. Where the data cannot leave your infrastructure at all, an open-weight model hosted in your own environment is the honest option, and we will be clear that it is meaningfully less capable so you can weigh that trade rather than discover it. Either way, what gets sent is logged and reviewable.
What usually comes with this
- BuildCustom Software DevelopmentCustom platforms, marketplaces and SaaS. We write the parts that are specific to your business and buy the parts that aren’t.Read more
- BuildWeb Application DevelopmentDashboards, portals and internal tools that hold up under real data volumes — not a prototype that falls over at ten thousand rows.Read more
- GrowDigital Marketing & SEOSEO and performance marketing measured against revenue, not impressions. We will show you the query data before you sign anything.Read more
- RunCloud & DevOpsDeploys that are boring on purpose. Infrastructure as code, real environments, and a bill you can read line by line.Read more
Thinking about ai & automation?
Start with a call rather than a brief. Thirty minutes, no deck, and an honest answer about whether we are the right people for it.