AI solutions that take care of repetitive work,
but the decision remains yours.

The price is determined by three things: how much well-organised data we're starting with, how many systems need to be connected, and whether the model runs in the cloud or on your own server. A narrow pilot can usually be scoped out within a few weeks, and that already shows the scale of the full deployment. Before we quote, we check whether there's a realistic return, because we don't take on work that won't pay for itself.

A well-scoped pilot is typically up and running within 2–4 weeks, while a full deployment with system integration takes more like 2–3 months. The longest part is almost always gathering and organising the data, not the development itself. That's why we start with a narrow process, so you have something concrete to work with early on.

With whatever is frequent, repetitive and well-defined: pre-screening incoming emails or quote requests, preparing product descriptions, drafting customer service replies, searching internal documents. The cost of a mistake is low here, while the savings show up every day.

What's not worth starting with: eye-catching but risky cases, such as automatic pricing or unchecked replies to customers. These can come later, once you have measurement and experience in place.

It's not a question of size but of repetition. If a task takes up several hours a week and is largely routine, it pays off even for a company with just a few people: the usage fee for cloud models starts from around €10 a month, and the development itself is a one-off cost.

In a small company, the typical problem is that there's no one to delegate to. There, a well-configured assistant genuinely frees up time rather than replacing headcount.

At the start of the project, we set out in writing which data leaves the system and which doesn't. For cloud models, we choose a provider that contractually rules out using your data for training and offers EU-based data handling. For sensitive data, personal fields are pseudonymised before they're even sent, and where full confidentiality is required, we use a model that runs locally instead.

Not for most tasks, because cloud models are cheaper and more powerful. Where data can't leave the company, though, we run a local model on our own Ubuntu VPS server. This means slower and more expensive operation, but in return no data ever leaves the building.

Yes, and it's not just the EU AI Act that requires it: transparency also builds trust. In practice, this means a short label on the chat interface and a sentence in the privacy notice explaining what data the system processes and how to reach a human.

High-risk use cases (such as an independent decision about credit or an employee) are subject to separate rules. The solutions we build are deliberately designed around human approval, so this category can be avoided.

Legally, the company in whose name the reply appears. That's exactly why we design the process so that, wherever a mistake would cost money or credibility, a human approves the output: the AI produces a draft, not a final answer.

This comes with logging: you can trace what happened and when, which source the answer came from and who approved it. That's worth the most if a dispute arises afterwards.

Yes, every language model can get things wrong, which is why we never let unchecked output go straight to a customer anywhere a mistake would cause harm. We restrict answers to the company's own documents and require a source alongside them, so it stays possible to verify where a claim comes from. If the model can't find support for an answer, it doesn't make one up, it hands the case over to a human.

Yes, today's models write and understand Hungarian convincingly. In our experience, though, without a specialist glossary and style rules, the text ends up sounding noticeably machine-written. That's why we put together the company's own terminology and a list of banned words for every project, so the output speaks in your brand's voice.

Before launch, we put together a test set from the company's real cases: typically 30–50 questions or documents with a known correct answer. We use this to measure what percentage of results are usable, and we run the same set again after every change.

In live operation, three numbers matter: how many cases it resolved without a human, how much time it saved, and how often its output needed correcting. Any more metrics than that just obscure the point.

We build the solution so the model can be swapped out, meaning it isn't tied to a single provider. When a new model comes out, we rerun the measurements and only switch if it genuinely delivers better results or cheaper running costs. This is part of the operating package.

To online stores, ERP and invoicing systems, email, databases and most other services with an API. Besides our own framework, we're equally at home with WordPress, WooCommerce and Magento 2. Where there's no API, we usually find another route, such as export and import based syncing.

MCP (Model Context Protocol) is an open standard that lets an AI assistant securely access a company's systems: query data, summarise it and prepare drafts, with precisely defined permissions. Without it, data has to be copied and pasted every time, which is slow and error-prone. This kind of connection already runs live on our own framework, so we won't be experimenting on your system.

This is called RAG: for a given question, the system first searches the company's own materials (contracts, quotes, product descriptions, internal policies), and only then formulates an answer based on the passages it found, with the source cited.

This has two advantages: the answer can be checked, and updating it doesn't require retraining the model, replacing the document is enough. For most business tasks, this is the right approach.

It's possible (this is called fine-tuning), but it's rarely worth it. It's more expensive, has to be repeated every time the data changes, and any mistake stays baked into the model afterwards, just harder to fix.

Fine-tuning makes sense where what's needed isn't knowledge but style or a strict format, for example every answer following the same structure. For knowledge, the document-based approach is the better choice.

What it takes over is repetitive preparation work: typing, searching, summarising, copying data. Decisions and approvals remain a human task, because that's where the responsibility lies too. In practice, colleagues typically end up spending more time on work that genuinely needs human judgement.

Whichever suits you better: either us, under an operating package, or your own team once we've trained them. Maintenance isn't a big job, but it does exist: refining prompts and rules, updating source documents, monitoring cost and errors, and keeping track of changes to the models.

Handover comes with written documentation, and every access belongs to your company. We don't build in dependency on us.

It consists of two items: the model's usage fee and the operating cost. The usage fee is proportional to the volume of text processed, so for an internal assistant it's often just €10–20 a month, and more for high-traffic customer service use.

Before deployment, we give you an estimate of the expected monthly cost and set a budget cap, so there are no surprises. Measured usage is visible throughout in the report.

That's exactly why we start with a pilot: a narrow, measurable task shows whether it's worth continuing. If the measurements don't bring the expected results, we'll tell you and stop there, we won't keep building on it.

Even then, the pilot leaves something useful behind: the organised data, the process description and the test set remain valuable later, even with a different tool.