AI solutions for business
UnderStack builds AI into concrete business workflows: extracting data from documents, answering questions from internal knowledge and automating repetitive steps, with cloud or local models and a person in control.
If you would prefer to talk through more details, we can find a time that works.
01
AI is useful where people spend hours on work that is repetitive but not quite regular enough for classic rules. An accounting team retypes supplier invoices that arrive in twenty layouts. An insurance or assessment firm reads long reports to find the same ten facts. A support team answers the same questions from a manual nobody can search. A sales team rewrites offers from earlier offers. A kitchen copies delivery notes into stock by hand. In all of these, a model can do the first pass: read, extract, classify, draft or search. The person then checks and approves. We do not build chatbots for the sake of having one. We look for a workflow with measurable friction, and build the smallest automation that removes it.
02
Most useful AI systems are ordinary software with a model in one or two steps. The surrounding software, such as permissions, review screens and logging, is what makes them safe to use at work.
03
Where the model runs is a business decision as much as a technical one. Hosted models are the fastest way to start and are suitable when the content may leave your environment under a data processing agreement. Local models run on your own computers or devices, so documents and conversations never leave them. We work with both. UnderStack Code, our assistant for Mac, runs local models through Ollama and keeps chats and files on the machine, and UnderStack Pocket AI is designed around on-device execution on Android. Before anything is built, we state which data would be sent where, so the decision is yours.
04
AI projects fail when they start from the technology. Ours start from one workflow and real examples of it.
05
The application around the model is built with React, TypeScript and Node.js, like our other software, so an AI feature can live inside an existing system instead of a separate tool. Models are reached through an API or run locally with Ollama. Three decisions are made explicitly in every project. First, what the model is allowed to do without approval: in our own products, edits, commands and other consequential actions wait for the user. Second, which data it can read: access is granted per source, not globally. Third, what is logged, so that an automated step can be audited afterwards. The model itself is treated as a replaceable component, because better and cheaper ones appear every few months.
06
Language models are good at reading, summarising and drafting, and unreliable at exact arithmetic, at facts they have not been given and at saying that they do not know. A well-designed system works around that. Figures are calculated by ordinary code, answers are grounded in your own documents with the source shown, and anything that changes data or leaves the company passes a person first. If a workflow needs an answer that is right every time without review, a model is the wrong tool and conventional software is the better choice. We say so during the first conversation rather than after the prototype.
07
An AI project has two cost components: building the automation, and running the model. The build depends on the workflow, the review screens and the integrations. Running costs depend on volume and on whether the model is hosted or local. Because the prototype is run on your own material first, you see the quality and an estimate of the running cost before committing to the full build. We do not publish price ranges. The article on AI automation for European businesses explains how to choose a first workflow, and you receive a quote before work begins.
Reading and extracting data from documents, sorting and routing incoming requests, drafting replies and summaries, and searching internal knowledge. It works best as a first pass that a person approves, not as an unattended decision-maker.
Only if you choose a hosted model, and then you know in advance which data is sent and to whom. With local models, documents and conversations stay on your own machines.
No. Most business automations use existing models and need a set of real examples to test against, not a training dataset. A few dozen representative documents are enough for a first prototype.
The prototype is measured on your own material, including the cases where it fails. In production, a person reviews the output where an error would matter, and exceptions are logged.
It depends on the workflow, the integrations and whether the model runs in the cloud or locally. We start with one workflow and a prototype, which keeps the first step small. You receive a quote before work begins.
Often, yes. If the existing system has an API or a database we can reach, the automation can read from it and write back to it, so the team keeps working in the same tool.
