How We Engage
Five ways to work with us on AI — including one where part of our fee depends on the results.
Fixed-scope assessment, pilot, value-based engagement, dedicated AI team or time and materials. We help you pick the model that fits the risk of the project, not the one that suits us.
AI ENGAGEMENT MODELS
Pay for clarity first, then for results.
The right contract depends on how much is already known about the problem.
Many AI projects fail on the contract before they fail on the technology. A fixed price for something nobody has measured yet pushes all the risk onto one side; an open-ended hourly budget pushes it onto the other. We prefer to reduce uncertainty in small, paid steps: first understand the process and the data, then prove the idea on real cases, and only then commit to a larger build — sometimes with part of our fee tied to the outcome.
Our team has been building and running production software since 2013, from Cluj-Napoca, on infrastructure we operate ourselves. The engineers who scope the work are the ones who build it and keep it running, so the people who make the estimate are the people accountable for it.
Small, fixed first steps
A discovery or a pilot has a fixed scope, a fixed duration and a written result. If the idea does not hold up, you stop there with a clear report instead of a half-built system.
Value you can measure
Where a process can be measured, we agree the metric and the baseline before work starts. Part of our fee can then depend on the improvement, verified on your own data.
You own what we build
The code we deliver belongs to you, together with the prompts, evaluation sets and documentation. Your data stays yours and is used only for your project.- Written scope, assumptions and exit points for every phase
- Baseline measured on your real process before we change it
- Success criteria agreed in writing, not after the fact
- Evaluation sets built from your own cases
- Regular demos on real data, not slides
- Delivered code, prompts and documentation owned by you
- Model-agnostic design: commercial APIs or open-weight models
- Option to run on our own cloud and GPU cloud in Romania
- Quality and cost monitoring after launch
- Senior engineers on every engagement, from scoping to support
THE ENGAGEMENT MODELS
Five models, one path
Most clients start with the first step and move along as the evidence grows.
Discovery and assessment
Fixed scope, fixed fee. We map the process, check the data and rank use cases by value and feasibility. You get a written report and a roadmap — see our AI readiness assessment.
Pilot / proof of value
A working version on a narrow slice of real cases, with success criteria agreed before we start: accuracy, processing time, share of cases handled. At the end you decide to scale, change or stop.
Value-based engagement
A base fee plus a component tied to outcomes agreed upfront — hours saved, processing time or error rate — compared against a baseline measured before work starts.
Dedicated AI team
A stable team on a monthly retainer for a roadmap of agents, integrations and improvements. Predictable capacity, shared priorities, one backlog. More about the dedicated AI team.
Time and materials
For work whose scope will change as you learn: you pay for the time spent, with weekly reports, an agreed budget cap and the freedom to reprioritise at any point.
Combine and switch
The models are not exclusive. A typical path is assessment, then pilot, then a value-based build or a dedicated team. You can change the model at every exit point.MEASURING VALUE HONESTLY
No baseline, no value-based fee
We would rather drop the model than argue about numbers later.
A baseline before we touch anything
Before any change, we measure the process as it runs today: how long a case takes from start to finish, how many people touch it, how often it is corrected or sent back. We use timestamps from your systems where they exist, and samples timed together with your team where they do not. When the data already sits in an ERP or a ticketing tool, process mining gives us an objective picture of the current flow.
Few metrics, defined precisely
We agree what counts as a case, what counts as an error, which period and which volume. Both sides can recompute every number from the same logs. We avoid vanity figures such as “tasks touched by AI” and prefer outcomes your finance team recognises: hours of work, cycle time, rework and errors caught before they reach a customer.
A fair comparison
Volumes, seasonality and team changes move the numbers too. We agree upfront how to normalise for them, run the old and the new process side by side where that is possible, and leave out periods affected by events outside the project. The measurement method is written into the contract, not improvised at the end.
What makes a use case suitable for value-based pricing
This model works well when:
- the process is repetitive and has enough volume to measure — invoices, orders, support tickets, documents;
- the data needed to measure it exists or can be collected without disrupting the team;
- the outcome depends mostly on the solution we build, not on decisions outside the project;
- someone on your side owns the process and can make the change stick;
- the approach has been validated in a pilot, so both sides know what is realistic.
It is a poor fit for exploratory research, for one-off projects without a stable process behind them, or when the main benefit is hard to quantify, such as better decisions or a better employee experience. In those cases we say so and recommend a fixed-scope or time and materials model instead.
Who owns what
The code we write for you under the engagement is yours, as set out in our contract, together with the configuration, prompts, evaluation sets and documentation. Open-source components keep their own licences, and third-party services such as model APIs remain under the terms of their providers. You can run the result with us, on your own servers or with another provider.
How we de-risk the work
Every phase ends with an exit point and a written result, so you never fund more than one step of uncertainty at a time. We build evaluation sets from your own cases before building features, keep a person in the loop for decisions that matter, and design so the model can be swapped: commercial APIs such as OpenAI or Anthropic Claude, or open-weight models such as Llama, Mistral or Qwen served with vLLM on our GPU cloud. For AI agents that act inside your systems, permissions start narrow and widen only after the logs show it is safe.
FAQ
Questions about how we engage
Short answers to what clients usually ask first.
Do you publish prices for these models?
No. Each engagement is scoped on the process and the data involved. After a first conversation we send a written proposal with the scope, the duration and the fee structure of the model that fits.
How much of the fee can be tied to results?
It depends on how reliably the outcome can be measured and how much of it depends on our work. We agree the split per project, in writing, together with the metric, the baseline and the measurement period. There is always a base fee that covers the work itself.
What happens if the agreed target is not reached?
The base fee covers the work delivered; the variable part follows the improvement that was actually measured. Because targets are set after a pilot, against a measured baseline, both sides know in advance what is realistic.
Who owns the code and the models?
You own the code we deliver, together with the prompts, evaluation sets and documentation. Foundation models such as GPT, Claude or Llama remain under the licences of their providers, and open-source components keep their own licences.
Can we start with a pilot without committing to the rest?
Yes. A pilot is a standalone engagement with its own deliverables. If the results do not justify going further, you keep what was built and the report, with no obligation to continue.
Not sure which model fits? Ask an engineer.
Tell us about the process you want to improve and the data behind it. We will suggest the model that fits and explain why.