Audit of what already runs
We look at what is in place, how it is connected and what it costs. Model spend is priced separately from infrastructure.
03 / CONSULTING
We work out why a deployed system is not delivering. Most often the model is fine and the problem sits in what gets measured, and where. The same discipline applies to software and IT decisions in general.
The typical picture: the system is live, the money is spent, and the effect is nowhere to be seen. The cause is rarely model quality. Usually something in the measurement is broken: an event fires on the wrong step, a metric counts the wrong thing, a report shows a number that affects nothing.
An audit starts by checking what is measured at all, and only then moves to the solution itself.
The same approach works beyond AI. Choosing a stack, a hosting model or a vendor, deciding whether to build or buy, reviewing an architecture before a large spend: these are software and IT decisions, and we take them the same way, numbers first.
We look at what is in place, how it is connected and what it costs. Model spend is priced separately from infrastructure.
We verify that events fire where they should and that the numbers in the report reflect reality.
We mark the places where the model can be replaced by a rule or plain code: cheaper, faster and more predictable.
Stack, hosting, build or buy, vendor review, architecture review before a large spend. Each decision comes with the cost of running it, on paper, before it is made.
A prioritised list of changes: what pays off at once, what needs rework, what can be left alone.
A telling case from our own practice: an ad account showed zero conversions on a key goal for months. The problem was neither the ads nor a model. The event fired on a step that users never reached: people got their result and left, and the system counted no result at all. Moving the event to the right step restored the real picture, and only then could the campaigns be optimised.
If the task is not for us, we say so in the first conversation and, where we can, point you to someone who fits.
Access to what already runs, and one person who knows the process from the inside. Without the second, an audit turns into reading code with no idea why it was written.
Yes, that is most of our audits. We read other people's code rather than rewrite it: the goal is to understand what is happening, not to replace everything with our own.
It depends on load and model choice, and the range is tens of times wide. Part of the audit is calculating that figure for your case and showing where it comes down without losing quality.
Yes. Stack and hosting choices, build versus buy, vendor and architecture reviews. The method is the same: what it costs to run, what breaks, how it rolls back.
We will look at where AI pays off and where it would cost more than it returns.