Services / AI Development
Apoliums builds AI features that are measured before they are shipped — retrieval over your own documents, extraction from the paperwork nobody wants to type, and models chosen on results rather than reputation.
Every AI project here starts with an evaluation set built from your real examples, because a system with no score can only be argued about. The model is then selected against that score, wired into your product with validation and a human review path, and re-tested whenever a provider changes something upstream.
What we build
These are the AI systems that hold up in production. Each one is defined by the task it takes over, not by the model behind it.
An assistant that answers from your contracts, manuals, tickets and records — and cites the source paragraph, so a wrong answer is visible instead of persuasive.
Invoices, purchase orders, medical forms, contracts and email turned into structured records your existing systems can read, with a confidence score attached to each field.
Drafting, summarising, search, tagging and next-step suggestions added to software you already run, behind a flag, without a rewrite of the surrounding application.
A single frontier model for everything is the expensive default. We measure candidates against your task and route by difficulty, keeping quality where it matters and cost where it does not.
Nothing reaches a user on a demo that felt good. Every prompt, model and retrieval change is scored against a fixed test set before it ships, and the score is visible.
What leaves your network, what is retained by a provider and what a model may see are decided in writing at the start, then enforced in the code path rather than in a policy document.
How we work
Reversing that order is why most AI pilots stall: without a score, nobody can say whether the last change made it better.
Step 01 / 05
We start from a task a person does today, with examples of it done well. If nobody can produce those examples, the task is not ready for a model and we say so before you spend money.
Task definition and examples
Step 02 / 05
Your real inputs with their correct outputs become the test set. It is written before the prompt, because a system with no scoring cannot be improved, only argued about.
Scored golden test set
Step 03 / 05
Retrieval strategy, prompt and model are varied against that test set. The result is a number per configuration, so the choice is made on evidence and the runner-up is recorded.
Measured configuration
Step 04 / 05
The winning configuration is built into the application with streaming, retries, timeouts, cost tracking and a human review path for anything the model is not confident about.
Feature behind a flag
Step 05 / 05
We roll out gradually, log every call, and re-run the eval suite whenever a provider updates a model — because a silent upgrade at the vendor is a change to your product.
Live feature with eval gate
Technologies
Model choice is an outcome of measurement, so this list is a starting set rather than a commitment made before your data is seen.
Stack manifest — 04 groups
21 components listed
01
Chosen per task on measured results, not on brand.
06 components
02
Postgres with pgvector until scale demands a dedicated store.
05 components
03
The AI layer sits inside a normal, testable service.
06 components
04
Every call is traced, scored and costed.
04 components
Questions
An AI development company builds software where a model does part of the work — reading documents, answering from a knowledge base, classifying records, drafting text. Apoliums covers the whole path: choosing the task, building the evaluation set, selecting and testing models, wiring the feature into your product, and monitoring it in production.
The engineering around the model is most of the job. Retrieval, validation, fallback behaviour, cost control and human review decide whether an AI feature is dependable, and none of them are settled by picking a model.
Apoliums quotes AI development per project after scoping, and separates two numbers: the build, which is one-off, and the running cost of model calls, which is ongoing and depends on volume. Build cost is driven by how messy your source data is, how many document types are involved, and how accurate the output must be.
We estimate the running cost during the prototype, when the tokens per request are measurable, and reduce it with model routing, prompt caching and batching before launch rather than after the first invoice.
Usually not. Apoliums starts with retrieval-augmented generation against an existing model, because most business problems are about giving the model the right context rather than teaching it new behaviour. Fine-tuning earns its place when you need a consistent output format or tone at high volume, and when you have labelled examples to train on.
Training a model from scratch is almost never the right answer for a business application. When fine-tuning is worth it, the evaluation set built in week one is what proves it beat the cheaper option.
Apoliums constrains what the model can say and then checks what it said. Answers are grounded in retrieved passages and cite them, outputs are validated against a schema before anything is written to a database, and low-confidence results go to a human review queue instead of straight into your records.
The evaluation suite includes cases the system should refuse, so a model that answers confidently when it should decline fails the gate before release rather than in front of a customer.
That is decided in writing before the build starts. Apoliums redacts personal data before any external model call, and where data cannot leave your environment at all, we run open models on your own infrastructure instead. Every prompt, output and access event is logged so you can answer the question during an audit.
Provider retention terms are read and recorded as part of the design, because they differ by vendor and by plan and they change.
A first production AI feature from Apoliums usually takes six to fourteen weeks. Roughly the first third is spent building the evaluation set and prototyping against it, and the rest on the application work — validation, review queues, cost controls and the interface a person uses to correct the system.
Projects run longer when the source documents have never been collected in one place. Getting the data ready is real work and it is scoped as its own step rather than hidden inside the estimate.
Next step
That is enough for Apoliums to tell you whether a model can do it, what accuracy is realistic, and what the running cost looks like — before either of us commits to a build.
