
Solutions
AI inside the product, only where it changes the outcome.
Language-model features built into the system you already run. With measured evaluation, written boundaries, and a person accountable for what comes out.
When it makes sense
Problems where a model contributes something real.
The useful question is not "where do we add AI?" but where reading and sorting work is eating hours today:
- Someone reads, classifies and forwards the same kind of message dozens of times a day.
- There is a document archive nobody uses because you cannot search it by what it says.
- Data arrives in documents of varying formats and gets typed in by hand.
- Support answers the same questions with information that is already written down.
- The same kind of document gets drafted over and over, with a few fields changed.
- An internal knowledge base exists and nobody uses it, because finding something costs more than asking.
What we build
Features, not an AI product.
Search over your own documents
Retrieval with context over company information, citing the source document so the answer can be verified.
Structured extraction
Turning invoices, contracts, forms or emails into structured fields, ready to enter the system.
Classification and routing
Sorting incoming items by type, priority or owning team, with a confidence threshold and an exit to human review.
Scoped assistants
Conversation limited to one domain and a defined set of sources, with what it may and may not answer written down.
Drafts with review
Generating the first version of a document or reply, which a person approves before it goes out.
Evaluation
A set of cases with expected answers, run on every change. Without it, "it got better" is an opinion.

How it is built
Rules we do not trade away to ship sooner.
Rules we do not trade away to ship sooner.
An AI feature is easy to demo and hard to sustain: what looks brilliant in a trial fails in production in ways nobody anticipated, on a real client’s data. These rules exist so the gap between the demo and the operation is not something the client discovers.
- No decision with consequences for a person is made without human review.
- Evaluation against real cases before launch and after every model change.
- Traceability: what was asked, with what context, and what the model returned.
- Client data does not feed third-party training without a written agreement.
- Cost per operation measured from day one, not discovered on the first invoice.
- The model provider is replaceable: it sits behind an interface of our own.
- LLM
- RAG
- Embeddings
- Google Cloud
- Firebase
How it is delivered
From use case to operation.
Use case
Which specific task, who does it today, and how we will know the system does it better.
Proof of concept
With the client’s real data, not with a demo example.
Evaluation
Cases with expected answers and a threshold agreed before going further.
Integration
Inside the system already running, with permissions, limits and logging.
Operation
Quality and cost tracking, and a review whenever the model changes.
Two things are worth separating. We have used generative AI inside our own delivery process for some time, and that part is demonstrable: it shows up in our timelines. As a product line for clients, it is a declared capability with no published case yet. If what you need is a vendor with years of AI systems in production, that is not us today, and we would rather say so here.
Is there one concrete task worth testing?
Tell us which one and who does it today. If it adds nothing, we will say that too.