We build AI into the systems you already run, with the scope defined first and one person accountable for it.
We build stores, websites and web applications.
A rule or an existing product often covers it.
The useful question is which part of a workflow genuinely needs judgement, and whether something simpler already covers everything around it.
A fixed rule suits work with a definite answer: a threshold, a mapping, a status change or a document that always arrives in the same format. It is predictable and repeatable. Where a rule covers the work, a model adds no useful judgement.
An existing product may already cover the requirement. A helpdesk, PIM, reporting tool or Shopify app can replace a custom build, with its supplier responsible for the product roadmap.
What is left is the part that reads language, weighs an incomplete case, or handles information that arrives in a different shape every time. That is the part worth building around a model, and defining it is what the scope has to settle first.
Each one reads language or handles information that changes shape.
Swipe the workflows
Merchandising
Descriptions, attributes and categorisation across a large catalogue, where source data arrives in a different shape from each supplier.
Service desk
Classifying, routing and drafting replies to tickets, emails, invoices and supplier documents that arrive in free text.
Finance
Reading figures from invoices, statements and reports that arrive in different layouts, then queuing them for comparison with source records.
In-product
A search, summary or drafting feature inside the store, portal or application your team already opens daily.
The model proposes. Agreed permissions and approval rules decide what happens next.
| What the software does | How it runs | Where a person decides |
|---|---|---|
| Reads records from a connected system | Read-only credentials, scoped to the fields it needs | Access is agreed before anything is connected |
| Classifies, drafts or summarises | The output is a proposal, held rather than actioned | Checked on screen before it counts as done |
| Writes back to a live system | Only through a defined action under its own restricted credential | Approved by a named user before each write, unless the agreement explicitly permits automatic writes to named fields |
| Meets a case it cannot handle | Routed out of the automated path | Picked up by a named person, with the context attached |
| Spends money on model and API usage | Budget and rate limits set per workflow | The ceiling is agreed up front and alerted on |
| Anything it has already done | Logged with the input, the output and the identity used | Reviewable afterwards without having to ask us |
The permissions hold whether the model behaves well or not.
Every stage ends with something you can act on.
The workflow as it runs today, the part worth automating, what the software may and may not do, and the acceptance criteria it will be judged against. It is a usable document for any developer, including one who is not us.
Where the main risk is model performance on your data, we test a sample of your own cases before pricing the rest of the build.
The interface, integrations, permissions and logging are placed where the work already happens, where the existing system supports it.
Documentation, a walkthrough for the people who will run it, and the access they need to do that. Ongoing support is a separate monthly decision rather than a condition of the build.
Discovery is quoted on its own and credited against the build.
Reliability, permissions, handoff and shutdown are agreed before launch.
A demonstration can show whether the idea works on a sample. These checks determine whether it is ready for live data.
Each of these is agreed with your team before anything runs on live data.
Published starting figures in GBP and USD, excluding VAT.
Scoped after discovery
Software, not a site
From £4,000From $5,200
Authentication, application behaviour, relational data, private merchant tooling or a custom Shopify app. Requirements beyond what a marketing site or a theme can hold.
Starting price · scoped after discovery
AI application delivery starts at £4,000 after discovery. Discovery is quoted separately and credited against the build if you proceed. Model and API usage is separate and depends on the provider and volume. Prices exclude VAT.
Turns a defined business requirement into software that uses a model where judgement is genuinely needed. Most of the work is the ordinary part: the interface, the integrations, the permissions, and the checks that catch a wrong answer before anyone acts on it.
Often not, and it is worth establishing first. A fixed rule is cheaper and more predictable, and an existing product may already do it for a subscription. AI earns its place where the input is language, the case needs judgement, or the information arrives differently every time.
Where it has an API and permissions can be scoped, usually yes. We review what the system will let a new component read and write before confirming the approach, because that constraint shapes the design more than the choice of model does.
We assume it will. Before launch we measure it against a test set of your real cases and decide what each kind of error costs. The design follows from that: approval before anything is sent or written, a route to a person, and a log of what happened.
AI application delivery starts at £4,000 after discovery, excluding VAT. Discovery is quoted separately and credited against the build if you proceed. Model and API usage is separate and depends on the provider and volume.
If you already have people to scope it, review the output and run it afterwards, a senior contractor may well be enough. Where nobody owns the workflow end to end, what is worth buying is one accountable party covering discovery, build, integration and a handover that names who runs it afterwards.
Before anything is connected, the scope names which data may be sent to a model provider and which must not. Provider retention and training terms are reviewed during model selection, and the agreed restrictions become acceptance criteria for the build.
You do, on the terms set out in the agreement. Ownership, and what happens to prompts and configuration at handover, is settled in writing before the build starts rather than left to assumption.
No. The pattern holds wherever the workflow lives: a catalogue, a helpdesk, a finance system or your own application. Commerce and operations are where we have the most context, which is why the examples on this page come from there.
How it runs today, who touches it and where it goes wrong tells us more than a feature list, including whether AI is the right answer at all.
