LLM FEATURES INSIDE THE PLATFORM YOU ALREADY RUN

AI that does a job, not a chatbot in the corner.

The bolted-on chat widget is the most common AI feature on the web and the least used. It sits in the corner, answers badly because it has no access to anything real, and gets quietly removed six months later.

The AI work that survives is embedded where people already are. Search that understands a question phrased badly. A summarise button in the editor. Ten thousand legacy articles tagged overnight instead of by an intern over three months. That is the work we take on.

Discuss an AI feature See what we have built
WHERE THE VALUE USUALLY IS
WORTH BUILDING
  • Search that answers questions
  • Drafting help in the editor
  • Summarising long documents
  • Auto-tagging legacy content
  • Classification and routing
USUALLY NOT
  • A chat widget with no data
  • Generating content nobody edits
  • Replacing a working search index
  • Anything touching payments
  • Features with no way to measure them
What we build

Five features, and what each one is actually for.

Every one of these has a measurable job. If a proposed feature has no way to tell whether it is working, that is usually a reason not to build it.

01

Semantic and RAG search

Search that retrieves from your own content and answers the question asked, rather than matching keywords and hoping. Works where a user knows what they want but not what you called it.

  • Content embedded and indexed for meaning
  • Retrieval before generation, with citations
  • Respects existing content permissions
  • Falls back gracefully when nothing matches
02

Editorial assistance

Drafting, rewriting, summarising, headline options and metadata generation, inside the CMS editor where authors already work rather than in a separate tool.

  • Summaries, excerpts and meta descriptions
  • Alt text suggestions for accessibility
  • Tone and length adjustment on selection
  • Every suggestion editable before it saves
03

Classification and tagging

The highest return work and the least exciting. Categorising, tagging and describing content at a volume nobody has the hours to do by hand.

  • Auto-tagging large legacy libraries
  • Alt text across an uncaptioned image library
  • Routing enquiries to the right team
  • Bulk cleanup during a migration
04

Summarisation at volume

Long documents, support tickets, research reports or transcripts turned into something a person can act on in thirty seconds.

  • Document and report summaries
  • Ticket and enquiry triage
  • Meeting and call transcript digests
  • Structured extraction into fields
05

Assistants worth having

Chat, but grounded in your documentation and content, with citations and a clear escalation path to a human when it should not be guessing.

  • Answers only from your own content
  • Citations on every claim
  • Escalation when confidence is low
  • Logged so you can see what is being asked
06

Evaluation and guardrails

The part that separates a demo from something you can leave running. Without it you cannot tell whether a prompt change made things better or worse.

  • Test sets of real questions and good answers
  • Regression checks before every release
  • Cost ceilings and rate limiting
  • Fallback behaviour when the API is down
How we build it

Retrieval first, generation last.

STEP 1

Work out whether AI is the answer

A good number of AI enquiries are better solved by a properly configured Solr index, a cleaner taxonomy, or a fixed form. Those are cheaper to build and cheaper to run. We look for that first, and say so when we find it.

STEP 2

Prepare the content

This is where the time actually goes. Content is chunked sensibly, cleaned, and embedded, with permissions carried through so a retrieval step cannot surface something a user should not see. Poor content structure limits the result far more than model choice does.

STEP 3

Build retrieval before generation

The retrieval layer is built and tested on its own. If the right passages are not coming back, no amount of prompt work will fix the answer, and it is much easier to diagnose in isolation.

STEP 4

Evaluate against real questions

A test set of genuine user questions with known good answers, run before every release. This is what makes it possible to change a prompt or swap a model without guessing whether you made things worse.

STEP 5

Ship with limits and fallbacks

Cost ceilings, rate limiting, caching for repeated queries, and defined behaviour when the provider is slow or down. An AI feature that takes the page down with it is worse than no feature.

Questions

What clients ask about AI work.

Which models and providers do you use?
Whichever fits the task and your constraints. OpenAI and Anthropic APIs most often, and open-weight models where data residency, cost at volume or offline operation matter. We design so the provider can be swapped, because this market changes faster than most contracts run.
Will our content be used to train someone else’s model?
Not on the enterprise API tiers we use, which exclude API data from training by default. Where the requirement is strict, we can run open-weight models in your own infrastructure so nothing leaves it. We confirm the position in writing before any content is sent anywhere.
What is RAG and why does it matter?
Retrieval augmented generation. Instead of relying on what a model absorbed during training, the system first retrieves the relevant passages from your own content, then asks the model to answer using those passages. It is what makes an assistant answer about your products correctly rather than plausibly, and it lets you show citations.
How do you stop it making things up?
Several things together. Retrieval so answers come from your content rather than model memory, prompts that instruct it to say when it does not know, citations so a reader can check, and an evaluation set of real questions with known good answers that we run before every release. It is reduced and made visible rather than eliminated, and anyone claiming otherwise is selling something.
How much does running an AI feature cost?
Ongoing API cost depends on volume and model choice, and for most CMS features it is smaller than clients expect, often tens of dollars a month rather than thousands. We design for it deliberately: caching repeated queries, embedding content once rather than per request, and using smaller models where a larger one adds nothing. You get an estimated monthly figure before we build.
Can you add AI to our existing Drupal or WordPress site?
Yes, and that is most of this work. It is built as a module or plugin inside your existing platform, using your existing content and permissions, rather than a separate system alongside it that has to be kept in sync.
How long does an AI feature take to build?
A well-scoped feature such as semantic search over an existing content library is usually a few weeks. The variable is rarely the model integration. It is the state of your content: how it is structured, how clean it is, and whether permissions have to be respected in what gets retrieved.
Do you use AI in your own development work?
Yes, openly. It handles scaffolding, boilerplate, test fixtures and repetitive refactors, and runs a review pass over every branch before a human opens it. It is not used for architecture, database schema, authentication or payment code, and every generated line is read by an engineer before it merges.
What if AI is the wrong answer for our problem?
We will say so. A meaningful share of the AI enquiries we get are better solved by a properly configured search index, a cleaner taxonomy, or fixing a form. Those are cheaper to build, cheaper to run and more reliable, and recommending them is how we would rather spend a first conversation.
Can you build AI features white-label for agencies?
Yes. We work inside your repository and process, and your client deals only with you.
Get in touch

Tell us what is slow or manual.

Describe the task that eats your team’s time, or the search box that never returns anything useful. Within one working day you get a reply from the engineer who would build it.

Before anything is signed, you get a written technical assessment: the real scope, where the risk sits, what we would build differently and why, and a fixed price against it. It costs nothing and it is yours to keep either way.

Reply within one working day, from an engineer Free written technical assessment Fixed scope and price before you commit
Request a technical assessment WhatsApp

Related

DRUPAL Drupal development Custom modules, theming, multisite, integrations and performance. WHITE LABEL White-label for agencies How we work under your brand, inside your repository and process. APPROACH Our delivery process The four stages every project runs through, and how Scrum sits alongside them.