Customisable AI Solutions: How to Scope, Build and Run Them

Off-the-shelf AI tools handle the obvious cases. The work that actually moves a P&L - the claims triage that needs to read your policy wording, the sales assistant that knows your pricing rules, the operations agent that talks to your AS/400 - tends to need something built for you. That is what customisable AI solutions are: systems assembled from foundation models, retrieval, tool use and your own data, shaped to a workflow that is specific to your business.

This guide covers how to think about them: where they earn their keep, what the architecture actually looks like, how to scope a first build without burning six months on discovery, and the operating model that stops them quietly degrading after launch.

What "customisable" actually means in 2026

The phrase covers a wide spectrum and conflating the levels causes most of the early scoping pain. There are roughly four tiers:

• Configured SaaS. You buy a product (Intercom Fin, Glean, Copilot for Microsoft 365) and configure prompts, knowledge sources and guardrails. Limited extensibility, fast to deploy, predictable cost. Suitable for ~60% of internal use cases.
• Workflow-level customisation. You compose AI calls inside an automation platform - n8n, Make, Zapier, Power Automate - alongside your existing systems. Good fit when the AI is one step in a larger process (classify this ticket, enrich this lead, summarise this transcript).
• RAG and agent systems. You build retrieval over your own corpus and wire an LLM into tools and APIs. This is where most genuine "AI solutions" sit: customer-facing assistants, internal knowledge agents, document processing pipelines.
• Fine-tuned or bespoke models. You adapt a base model (LoRA on Llama or Mistral, or OpenAI fine-tuning) for a narrow task where prompting plateaus. Rare. Justified when you have volume, repetition and measurable accuracy gaps.

Most projects that get labelled "custom AI" land at tier two or three. Tier four is overused as a pitch and underused as a tool - it is the right answer maybe one time in fifteen, usually for classification, extraction or domain-specific style.

Where customisation pays back, and where it does not

The honest test for whether you need a custom solution is: does the value depend on your own data, rules or systems? If the answer is no - if a generic model with a good prompt would do the job - buy the SaaS. If yes, you are looking at a build.

Cases where custom work consistently pays back:

• Document-heavy operations where the source material is yours: contracts, claims, clinical notes, supplier invoices, policy documents. Generic tools cannot read your taxonomy.
• Customer support over a proprietary product, where the assistant needs your release notes, your account data and your refund rules. Off-the-shelf bots regress on accuracy as soon as the product evolves.
• Sales and revenue operations that integrate CRM data, pricing logic, territory rules and product catalogues. Salesforce Einstein or HubSpot Breeze handles the basics; the differentiated workflows need code.
• Internal search and knowledge work across multiple systems (Confluence, SharePoint, Notion, Slack, a file share, a ticketing system). Glean does this well; bespoke RAG does it cheaper at scale and with tighter access control.
• Regulated workflows where you need defensible audit trails, data residency control and the ability to swap models without rebuilding the application.

Cases where it usually does not pay back: meeting summaries, generic content drafting, code completion, basic translation. These are commodity. Pay the SaaS fee.

The reference architecture

Most production AI systems we build share the same shape. It is worth describing it explicitly because vendors often obscure it.

Model layer

One or more foundation models reached through an API. In practice, a sensible default is to support at least two providers (OpenAI plus Anthropic, or one of those plus a self-hosted Llama variant) so you can route by cost, latency or capability and survive a vendor outage. Artificial Analysis tracks comparative benchmarks if you want current numbers.

Retrieval layer

For anything that touches your data, you need retrieval. The typical stack is a vector database (pgvector inside Postgres for most cases, Pinecone or Weaviate if you need scale or filtering complexity), a chunking and embedding pipeline, and a hybrid search layer that combines semantic and keyword search. Pure vector search underperforms hybrid by a wide margin on real corpora - the RAG survey literature has been clear on this for two years.

Orchestration layer

This is where the application logic lives: prompt construction, tool selection, retry handling, evaluation hooks. LangChain and LlamaIndex are the obvious frameworks; plenty of teams ship without them in plain Python or TypeScript. The choice matters less than having clear boundaries between prompt logic, tool calls and business logic so you can test each independently.

Tool and integration layer

The connections to your real systems - CRM, ERP, ticketing, internal APIs, databases. This is usually the most underestimated part of the build. Auth, rate limits, schema drift and error handling consume 30-40% of engineering time on a typical project.

Evaluation and observability

You need a way to measure whether the system is getting better or worse. That means an evaluation set (50-300 representative inputs with expected outputs), automated scoring on every change, and production logging of inputs, retrievals and outputs. Tools like Langfuse, Braintrust or Arize work; a Postgres table and a notebook works too. The point is having the data, not the brand.

Guardrails and refusal patterns

Prompt injection defences, PII redaction on inputs and outputs, refusal patterns for out-of-scope questions, and rate limiting. The OWASP Top 10 for LLM Applications is the canonical reference and worth reading before you ship anything customer-facing.

Build, buy or compose

The three-way decision - buy a SaaS, compose on a platform, or build bespoke - is the one that determines cost and time-to-value more than any other. A reasonable heuristic:

• Buy when the use case is generic, the data is non-sensitive and the vendor has a credible roadmap. Total cost over three years is almost always lower than building, even if the licence looks high.
• Compose on a platform (n8n, Make, Power Automate, or a low-code AI layer like Vellum or Relevance) when you need orchestration across systems but the AI logic is straightforward. This is where the majority of mid-market projects belong - the cost curve is favourable and the maintenance surface is small.
• Build bespoke when accuracy requirements are strict, the data is sensitive, the workflow is core to your differentiation, or you need control over the model and deployment. Expect 8-20 weeks for a first production system and ongoing engineering time afterwards.

The mistake we see most often is composing when the right answer was to buy, or building when the right answer was to compose. The cost of that mistake usually shows up six months in, when the team is maintaining infrastructure that adds no commercial value.

Scoping a first build without burning six months

The fastest route from idea to working system is to compress discovery, narrow the scope and ship something small that handles one workflow end to end. The pattern that works:

Weeks 1-2: discovery and specification. Pick one workflow. Map the current state with timings and volumes. Identify the data sources, the decision points and the failure modes. Define what "good" looks like in measurable terms (resolution rate, accuracy on a test set, time saved per case). Write a one-page specification that an engineer could build from.

Weeks 3-6: thin slice to production. Build the smallest possible version that touches the real systems and handles the real data. No edge cases yet. Get it in front of two or three users.

Weeks 7-12: harden and broaden. Add the edge cases the pilot users hit. Build the evaluation harness. Add monitoring. Roll out to the full user group.

Weeks 13+: operate and iterate. Weekly or fortnightly improvements driven by production logs and user feedback. This is the phase where most of the value compounds.

Projects that fail tend to fail in weeks 1-2 by over-scoping, or in weeks 7-12 by treating the pilot as the finished product. The discipline is to keep the scope narrow and the iteration loop short.

Security, data residency and compliance

For UK and EU buyers, three questions need answers before any custom AI work goes near production data.

Where does the data go? Most model providers now offer EU or UK data residency. OpenAI's enterprise tier supports European data processing; Anthropic and Google offer similar. For sensitive workloads, self-hosted models on AWS Bedrock, Azure OpenAI in a UK region, or a Llama variant on your own infrastructure remove the question entirely.

What does the GDPR position look like? The ICO's guidance on AI and data protection is the authoritative reference. The practical implications: you need a lawful basis for processing, a DPIA for high-risk use cases, clear data minimisation, and a documented position on automated decision-making under Article 22 if the system makes decisions that affect individuals.

How do you handle the EU AI Act? Most internal workflow systems fall under "limited risk" or "minimal risk" classifications. Customer-facing systems, hiring tools, credit decisions and biometric applications are higher-risk and need additional documentation. The EU AI Act tracker covers the staged compliance deadlines.

None of this is exotic. It is the same kind of governance discipline that any production data system needs. The trap is treating AI as a separate category and rebuilding governance from scratch, rather than extending the controls you already have.

What it costs and how to budget

Real numbers, based on UK mid-market pricing as of 2026:

• Discovery and specification: £8k-£20k for a focused two-week engagement covering one workflow.
• First production build: £25k-£120k depending on scope, integration complexity and accuracy requirements. A RAG assistant over a single corpus sits at the lower end; a multi-system agent with real-time integrations sits higher.
• Ongoing operation: £3k-£15k per month covering model costs, hosting, monitoring and iteration. The model cost component is usually 20-40% of this for a well-engineered system - much higher if no one has tuned prompts or retrieval.
• Internal cost: at least one engineer's attention, even if the build is outsourced. Custom AI systems do not run themselves; they need an owner who watches the evaluation dashboard and decides what to fix next.

Payback periods we typically see: 4-12 months for operational automation, 12-24 months for customer-facing systems where the value is qualitative (better experience, faster response). The honest answer to ROI questions is that it depends heavily on whether you measure baseline performance before the build - and most teams don't, which makes the after-the-fact case impossible to defend.

The operating model after launch

The most common failure mode is not a bad build. It is a good build that no one owns. Six months after launch, the model has been deprecated, the retrieval index is stale, two integrations have changed schema, and accuracy has dropped 15% without anyone noticing.

A sustainable operating model needs four things:

• A named owner who is responsible for the system's commercial outcome - not just its uptime. Usually a head of operations or a product manager.
• A weekly review of evaluation metrics, production errors and user feedback. Thirty minutes is enough if the dashboard is good.
• A monthly improvement cycle: pick the top three issues from production logs, fix them, redeploy, re-evaluate.
• A quarterly architecture review: are we still on the right model, the right retrieval approach, the right cost structure? Model pricing and capability shift fast enough that this matters.

Run this for a year and a custom AI system is genuinely a competitive advantage. Skip it and you have an expensive demo that quietly stopped working.

FAQs

How long does a custom AI solution take to build?

For a well-scoped first workflow, expect 8-16 weeks from kickoff to production. The first two weeks are discovery and specification. Weeks three to six produce a thin slice in production with real users. Weeks seven to twelve harden the system and broaden the user base. Projects that take longer usually have one of two problems: scope that expanded during discovery, or a decision to build infrastructure that should have been bought. Keeping the first build narrow - one workflow, one user group, one success metric - is the single biggest predictor of hitting the timeline.

Should we build in-house or use an agency?

The honest answer depends on whether you have the team. Building in-house works when you have at least two engineers with LLM and integration experience, a product owner with capacity, and tolerance for a 4-6 month learning curve. Using an agency makes sense for the first one or two systems, where the value of compressed time-to-value and accumulated patterns outweighs the cost premium. The pattern we see working: agency-led for the first build, with two of the client's engineers embedded throughout, then in-house ownership from month four onwards with the agency on retainer for harder problems.

What does ongoing cost look like, realistically?

For a mid-market production system, budget £3k-£15k per month all-in. Model API costs are usually 20-40% of that - a customer-facing RAG assistant handling 5,000 conversations a month typically runs £400-£1,200 in model spend. Hosting and infrastructure add £200-£800. The remainder is engineering time for monitoring, iteration and incident response. Costs scale roughly linearly with usage until you hit a point where caching, smaller models for routing, or self-hosting start to make sense - usually around £4k-£5k a month in model spend.

How do we handle GDPR and the EU AI Act?

Start with the ICO's AI and data protection guidance, which is the authoritative UK reference. The practical steps: identify your lawful basis for processing personal data, run a DPIA for any high-risk use case, document your position on automated decision-making, and ensure your model provider offers a data processing agreement and UK or EU data residency. For the EU AI Act, classify your use case (most internal workflows are limited or minimal risk), document the classification, and track the staged compliance deadlines through 2026-2027. Treat AI governance as an extension of your existing data governance, not a separate stack.

How do we avoid being locked into one model provider?

Architect for portability from day one. That means abstracting model calls behind your own interface rather than calling provider SDKs directly, keeping prompts and evaluation sets in version control independent of any vendor, and storing your retrieval index in infrastructure you control (Postgres with pgvector is the most portable option). Many teams support two providers in production from launch and route by cost or latency. The cost of this design is modest - maybe 5-10% additional engineering time - and the optionality has paid back consistently as model pricing and capability have shifted over the last 18 months.

What is the difference between RAG and fine-tuning, and which do we need?

RAG (retrieval-augmented generation) gives the model access to your data at query time by retrieving relevant chunks and injecting them into the prompt. Fine-tuning adapts the model itself by training on examples. For most custom AI solutions, RAG is the right answer: it handles changing data, gives you control over what the model sees, and is far easier to debug. Fine-tuning is justified for narrow, repetitive tasks where the format or style matters (classification, structured extraction, domain-specific tone) and you have hundreds to thousands of high-quality examples. The two approaches combine well - a fine-tuned model on top of a RAG pipeline - but start with RAG and only fine-tune when prompting plateaus.

How do we measure whether the system is actually working?

You need an evaluation set and production metrics. The evaluation set is 50-300 representative inputs with expected outputs or quality criteria, scored automatically on every change so you can see regressions before they ship. Production metrics depend on the use case: resolution rate and escalation rate for support assistants, accuracy and review rate for document processing, conversion lift for sales tools. The most underrated metric is user behaviour - how often do users accept the AI's suggestion, edit it, or override it? That data tells you more about real performance than any benchmark.

What happens when the underlying model is deprecated or changes?

Model deprecations are now a routine operational event - OpenAI, Anthropic and Google all run staged deprecation schedules with 6-12 months of notice. If you have abstracted model calls, kept your evaluation set current and have a weekly operating cadence, a model migration is a 1-3 week project: run the evaluation suite against the new model, adjust prompts for any behaviour differences, A/B test in production, switch over. If you have not done that work, the migration becomes a panic project. The ongoing operating model described above is what makes deprecations boring rather than dramatic.

Where to go from here

The decision points are usually clear once you separate them: is this use case generic or specific to us, do we need integration or composition, do we have the team to operate it, and what is the measurable outcome we are buying. If you can answer those four questions, you can scope a custom AI solution sensibly. If you cannot, the first investment should be two weeks of structured discovery, not six months of building.

If you want to talk through a specific workflow - what tier of customisation it actually needs, what the build would cost, and what the operating model looks like afterwards - AI Advisory runs fixed-fee discovery engagements that produce a costed roadmap you can act on with us or take to any other team.

Ready to put this into production? book a discovery call.