How we work

The first call

About an hour, on video. It costs you nothing.

We start by listening: what you are building, who will use it, and what success looks like.

We ask about the users and what they do today without the feature. We ask about the data: where it lives, how clean it is, who may see which part of it, and whether it has to stay inside the European Union. We ask about the limits that matter to you, such as budget, deadlines, the systems we must connect to and the rules your company already follows.

By the end of the call we can usually tell you three things: whether AI is the right tool for the problem, which approach we would try first, and what we would need from you to begin. If AI is the wrong tool, we say so on the call. Some problems are better solved with a search box, a rule or a form, and that answer is worth more to you than a project.

The written proposal

Sent after the call, so you can share it inside your company.

A short, plain proposal: what we build, how we measure it, and what it costs.

You get it a few days after the call.

What it covers

The goal in one paragraph. The scope: what is in the first version and, just as important, what is not. The measures of success we agreed on. The architecture we would start with and the models we would test.

What it commits to

A timeline in rounds, with what you see at the end of each one. The price, so you know the number before any work starts. The risks we can already see, and what we will do if one of them turns out to be real.

Nothing starts until you accept the proposal. If something in it is wrong, we change it together first.

The first month

Every project starts the same way, whatever its size. In week one we learn the goal, the users and the data, and we write down how we will measure success. In week two we choose the architecture and the models, and we build the first test set from real cases, before we build the feature.

In weeks three and four the first working version runs against those tests. You see it, you try it, and you see its numbers: how often it is right, how fast it answers and what each answer costs.

At the end of the month you decide whether to go on, with real numbers in hand instead of a promise. Most projects go on. Some change direction, and that is a good result too, because the month cost far less than a wrong product.

Week one

A call about the goal and the users1 hour

Data and access review2 days

Risks and constraints written down1 day

How we will measure successin writing

Week two

Architecture and model choice2 days

First test set from real cases50–100 cases

Safety rules and limitsin writing

Tracing switched onfrom day one

Weeks three and four

First working roundshown to you

Test results and costswith each release

Feedback from your teamone session

The plan for the next roundsagreed together

A working first version, its tests and a plan4 weeks

After each round

A round is one or two weeks long. It ends with something you can use and the evidence that it works, never with a slide that says it will.

Working software

A version you can open and try, in a test environment or behind a switch in your product. Not a recording and not a mock-up.

A link to try it
Release notes
Known limits

Test results

The test set run against the new version and the one before, so you can see what got better and what got worse.

Quality per test group
Failures, with examples
New cases added

Speed and cost

How long an answer takes and what it costs, measured on real requests, with a forecast for your expected traffic.

Time per answer
Cost per answer
Monthly forecast

Decisions to make

Every round raises a few questions only you can answer, such as a trade between cost and quality. We bring them with our advice.

Options, side by side
Our recommendation
The next round’s plan

A round report

This is the shape of the short report you get at the end of a round. It fits on one screen, because nobody reads the second one.

The numbers come straight from the test set and from the traces in your test environment. When a number gets worse, the report says why and what we will do about it.

Support assistantRound report

Round report, support assistantRound three of six: answers about refunds and delivery

The assistant now answers delivery questions from the courier’s own tracking pages. Refund answers improved after we split the policy document by country. Two kinds of question still go to a person on purpose: damaged goods and invoices.

Test set: 180 casesCompared with round two

The numbers in this round

Correct and complete answers Up from 81% in round two88%
Answers with a source shown Every answer must cite one100%
Handed to a person By rule, as agreed14%
Median time to the first word Measured in the test environment0.9 s
Cost per answer Down after we shortened the prompt$0.003

Next round: invoicesDecision needed: none

An example. The product, the test set and the numbers are made up for this page.

Launch

Launch is a quiet day when the work before it was done well.

We release to a small group of users first, watch the traces and the costs, and widen the group when the numbers hold. If something goes wrong, we can switch the feature off or roll back in minutes.

Handover

Your team can run the feature without us.

The code is in your repository from day one, so handover is about knowledge.

We write down how the feature works, how to run the test set, how to read the traces and the cost reports, and what to do when an alert fires. We walk your developers through it on a call and answer their questions afterwards. When a prompt or a model has to change, your team knows how to change it safely: change it, run the tests, compare the numbers, then release.

The retainer

For features that are already live.

AI features need care after launch, because models, prices and users keep changing.

Providers release new models and change their prices. Users find questions nobody thought of, and the data the feature reads keeps growing.

A retainer gives you a set amount of our time each month. We use it for new features, model and prompt updates, fixes, and the monthly report on quality, speed and cost. We agree the amount and the fee in the proposal, and we adjust it when your needs change. Many retainers start at the end of a project with us, but we also take over features that someone else built, after a short review.

How a project ends

On a date you know in advance.

A project ends when the feature is live, measured and handed over.

That is written in the proposal from the start. At the end you get a short final report: what we built, how it performs against the measures we agreed at the start, what we would do next and what we would watch.

Then you choose. You can run the feature yourselves, keep us on a retainer, or come back when the next feature is ready to start. All three are normal.

How we stay in touch

In English. All our calls, documents and code are in English. We work on European hours from Romania and overlap well with the rest of Europe, the UK and the morning in North America.

On video. One short call a week, at a fixed time, for the people who decide. A longer call at the end of each round to show the work. Other calls only when they save time.

In writing. A short written update every week: what we did, what we learned, what is next and what we need from you. Decisions are written down, so nobody has to remember a call.

In your repository. We work in your Git repository and your issue tracker, or in ours if you prefer. You can see every change as it happens, not only at the end of a round.

Weekly updateFriday

Weekly update, FridayWeek two: test set ready, first prompts running

Done. The test set has 74 real questions from your support inbox, each with the answer your team would give. The first version of the assistant runs against it every night.

Learned. A third of the questions need the order history, not only the help pages. We will connect it next week.

Need from you. Read access to the orders API by Wednesday.

An example. The project and its details are made up for this page.