Custom LLM applications “Our own model” almost never means: training it ourselves.

Usually a good base model is enough, connected to your data, with clear rules for access, review and cost. We build such LLM applications and tell you up front which approach is the smallest one that fits your task.

Have a workflow reviewed

Four approaches

The smallest one that fits wins.

  • Fixed rules, no model

    When the same input should always give the same result. Rules, templates and APIs are then cheaper and more reliable.

  • Answers from your sources

    When knowledge changes and every answer must be traceable to its source. Requires settled access rights and clean documents.

  • Model with tools

    When a task touches several systems. The model picks approved tools; rights and checks stay outside of it.

  • Fine-tuning

    Only when prompts and sources repeatedly miss a clearly measurable behaviour. It replaces neither missing knowledge nor permissions.

Decide first

An LLM is only worth it if the problem needs one.

Well suited

  • knowledge is spread across documents, systems and permissions,
  • inputs are unstructured: tickets, contracts, emails, free-form requests,
  • errors can be caught by a rule, a check or a cited source.

A simpler system will do

  • the rule is already clear and a query gives the right result,
  • there is no reliable source,
  • high-stakes errors cannot be checked.

If an LLM adds no measurable value, we say so before a pilot spends budget.

Examples

Approaches, not case studies. With a visible checkpoint.

  • Support copilot

    Draft reply from product docs, customer context and known incidents, with sources and an uncertainty note. A support agent edits and sends.

  • Contract intake

    Extract terms, compare them with policy, flag unclear clauses instead of faking a confident answer. A person resolves the exceptions.

  • Internal assistant with actions

    Answer operational questions with sources and prepare a system action. It only runs after explicit confirmation.

Acceptance

“Looks good” is not an acceptance criterion.

  1. Collect test questions

    Real requests from your daily work, including the hard ones and the unanswerable ones.

  2. Define criteria

    Correctness, source grounding, declining when nothing is there, response time and cost per request.

  3. Pilot against criteria

    Acceptance is based on the agreed values, not on a polished demo.

  4. Re-check with every change

    New prompt, new source, new model: the test questions run again and reveal regressions.

Off-the-shelf models don’t know your SKUs. Yours will.

We look at your task and tell you whether it needs rules, retrieval, tools or really a trained model.

Have a workflow reviewed
Measuring tape, tailor’s chalk and scissors