
Build
Custom AI applications
Applications built around your own process and data, shipped to production with the evaluation, oversight and monitoring that make them defensible — and handed over with the documentation your team needs to own them.
Duration
8–16 weeks to first production release
Built on
ISO/IEC 42001 · ISO/IEC 27001:2022 · EU AI Act
Indicative price
€25,000–65,000 per engagement
Who this is for
COO
Has a process that costs too much and no product on the market that fits it.
CIO or CTO
Needs it built to a standard the organisation can still maintain after handover.
Head of a function
Has a specific bottleneck and a budget, and wants something working this quarter.
Compliance officer
Must be able to say what it does, on what data, under whose oversight.
The model is the cheapest part
Buying a product is usually the right answer. Where a product fits your process, configure it and move on — custom software is the more expensive option and it stays expensive, because somebody has to own it for as long as it runs. We say this before quoting, and a fair number of these conversations end in a recommendation to buy something.
Custom becomes right in three situations: the process is your differentiator and bending it to fit a product would cost more than building; the data cannot leave a boundary that products do not respect; or the integration surface is so specific that a product's ninety per cent fit creates more work than it removes.
When it is right, the model is the cheapest part of what you are buying. The cost sits in the data work, the integration, the evaluation harness, the oversight design, the monitoring, and the documentation that lets somebody else maintain it. A quote that covers only the model is a quote for a prototype, and the distance between a prototype and something you can run a business on is where most AI budgets disappear.
Evaluation is what separates the two. A demo is judged by whether it impressed the room. A production system is judged against a test set with known answers, on every release, with a threshold that blocks the release when it regresses. Building that harness early feels slow, and it is the reason the system is still trusted in month nine.
We build model-agnostically and we are not a reseller of any AI platform. That matters more than it sounds: the cost and capability of the underlying models are moving fast, and an application welded to one provider carries a repricing risk you never agreed to. Where data cannot leave a jurisdiction, that belongs in the first architecture session rather than at deployment.
How we do it
- 01
Discovery and design
2–3 weeks
The process as it actually runs, the data available, the integration points, and what the system must not do. Ends with a design, an evaluation plan and a cost you can decide on. If the answer at this point is buy rather than build, we say so.
- 02
Data and evaluation harness
2–3 weeks
Data access, preparation and permissions — and the test set with known answers that every release will be judged against. Built before the application, not after it.
- 03
Build
4–8 weeks
Iterative, with working software in your hands from the first fortnight. Human oversight designed into the workflow rather than bolted on as a review step nobody has time to perform.
- 04
Integration and hardening
2–3 weeks
Into the systems where the work actually happens. Authentication, authorisation, logging, rate and cost controls, and failure behaviour that degrades safely.
- 05
Pilot with real users
2–3 weeks
A defined group, real work, measured against the baseline. The changes that come out of this are usually about the workflow around the system rather than the model inside it.
- 06
Production and handover
1–2 weeks
Deployment, monitoring, alerting and runbooks. Documentation written for whoever maintains it, and a named owner in your organisation before we finish.
Named artefacts
What you receive
- Solution design, including the build-or-buy argument
- Evaluation harness and test set, yours to keep and extend
- The application, in production, integrated with your systems
- Human oversight design — where a person intervenes, and how they can realistically disagree
- Logging and audit trail sufficient for an ISO 42001 or EU AI Act conversation
- Monitoring, alerting and cost controls
- Runbooks and failure procedures
- Technical documentation and handover to a named owner
- Model dependency assessment and the switching path
- Measured pilot result against the baseline
What we need from you
- A product owner with decision authority and real hours. Their absence is the most common reason a build slips.
- Data access arranged early. Waiting for access is the largest avoidable delay in every project of this kind.
- Pilot users who will use it on real work and say what they think.
- A named owner for after go-live, agreed before we start building rather than at handover.
- Acceptance that we may come back and recommend buying instead.
What changes
- 01A system in production, judged against a test set rather than against a demo.
- 02Oversight designed to be operable, so it survives both an audit and an incident.
- 03No lock-in to a single model provider, and a known switching path if one is needed.
- 04Your team can maintain it, because it was documented and handed to a named person.
- 05The pilot result is a number against a baseline rather than an impression.
What it costs
€25,000–65,000 per engagement
All prices exclude VAT.
Questions
Should we build or buy?
Buy, unless the process is your differentiator, the data cannot leave a boundary products do not respect, or the integration surface makes a product's fit more work than it saves. Discovery answers this properly, and we have ended engagements there with a recommendation to buy.
Which models do you use?
Whichever fits the task, the cost envelope and the data constraints. We are not a reseller of any AI platform and have no incentive to steer you. We design so the model can be changed, and we tell you what changing it would cost.
Can it run somewhere our data is allowed to be?
Yes, and the constraint belongs in the first architecture session rather than at deployment. Where the requirement is that data does not leave a jurisdiction or a tenancy, that shapes both the model choice and the hosting — see sovereign hosting in our Cloud & Cybersecurity line.
What happens when the model changes underneath us?
The evaluation harness catches it. That is its second purpose — providers update models, behaviour shifts, and without a test set with known answers you hear about it from a user. With one, you hear about it from a failing threshold.
What does it cost to run?
We give you a run cost at design time, separated from build: inference, hosting, monitoring and the maintenance effort. Run cost is where estimates are usually silent, and it is the number that decides whether the business case holds in year two.

Leave with your top three risks documented
Thirty minutes with a senior practitioner. No slideware, no sales engineer.