- Home
- FAQ
FAQ
Questions we get asked, answered properly.
Including the ones about ownership, exit points and what happens when a project goes wrong — which are usually the questions that actually matter.
We build production machine learning and AI systems end to end — data pipelines, models, serving infrastructure, evaluation and monitoring — and hand them over to your team documented and running in your own environment. We are an engineering firm, not a software product company and not a staffing agency.
A data scientist will usually get you to a strong prototype. Turning that prototype into something that runs unattended is a software engineering problem — serving, retries, monitoring, cost control, evaluation in CI, failure behaviour. Most stalled AI projects have a competent model and none of that. We do both halves, and increasingly we are hired specifically for the second one.
That is a good position and a common starting point. We would run a shortened diagnostic focused on production-readiness: what breaks under real load, what the evaluation set does not cover, what happens when the model is wrong, and what it will cost per request at your actual volume. From there it is usually a hardening engagement rather than a rebuild.
A diagnostic is two to three weeks. A first production system is typically three to six months depending on data readiness and how many systems it has to integrate with. Anyone quoting a fixed duration before seeing your data is guessing, and you should treat the quote accordingly.
No, and if you wait for that you will wait indefinitely. Assessing the true state of your data is part of the diagnostic. What matters is that the data exists and that someone can explain how it was recorded — messy is workable, absent is not.
No. Client data is used for that client's engagement and nothing else. Where a third-party model provider is involved, we tell you exactly which data reaches them under what terms, and where the requirement is that none of it leaves your environment, we design for self-hosted models from the start.
Yes. We deploy into your cloud account by default, and on-premise where data residency or regulation requires it. Self-hosted open-weight models are a normal option rather than a special case, and for steady high-volume workloads they are frequently cheaper than a metered API.
Phase boundaries are genuine exit points. You keep everything produced up to that point — code, documentation, evaluation sets — in your own repository. We do not structure engagements so that stopping early leaves you with nothing usable.
Yes. We work with clients in Europe, the Gulf and North America, with an agreed overlap window for meetings. Where the work involves personal data crossing borders we address the transfer and residency requirements during scoping, not after.
Routinely, and we are content to work under yours. Where we handle personal data on your behalf we expect a data processing agreement to be in place before any data moves.
From funded startups to established manufacturers and financial institutions. The practical requirement is not headcount — it is that someone internally owns the problem and can make decisions about it. Projects without that person tend not to finish, whatever the budget.
Yes, and we will give you a frank assessment of what we inherit. Sometimes the sensible recommendation is to keep the existing model and rebuild everything around it; occasionally it is to start again. We will tell you which, with reasons, and we have no commercial interest in inflating the answer.
Next step
Still unanswered?
Ask us directly. Technical questions reach an engineer, not a sales inbox, and you will get a real answer rather than a callback request.