Frequently asked questions.

Discovery first — two to four weeks establishing what is buildable, what it should cost and how success will be measured. Then a scoped build, usually six to sixteen weeks. Then either handover to your team or an ongoing arrangement, decided explicitly rather than by default. We do not have a minimum contract length and we do not require a retainer to start.

A discovery engagement is typically €8–20k depending on scope. A focused build lands between €30k and €120k. Ongoing fractional arrangements run €4–9k a month. All figures are in EUR and exclude VAT. Those bands are rough estimates drawn from past client work, and they are wide because scope varies enormously. Every project is quoted on its own scope after a scoping call; large or multi-phase programmes sit outside the bands entirely and get a proposal written for them.

Entirely. Code in your repositories, infrastructure as code in your accounts, any fine-tuned weights yours. No proprietary platform, no licence, no runtime dependency on us. If your team wants to take it over, we write the handover documentation as part of the work rather than as a paid extra.

Usually one to three weeks depending on current commitments. If you need something faster than that, tell us on the first call — occasionally we can, and if we cannot we would rather say so than let a deadline slip quietly.

Yes, and we do regularly. A meaningful share of enquiries resolve to an off-the-shelf product plus a week of integration, or to a process fix that needs no AI at all. Taking on a project we expect to fail costs us more in reputation than it earns in fees.

Whichever fits the workload — Claude, GPT, Gemini, and open-weight models like Llama, Mistral, Qwen and DeepSeek where self-hosting is required. We are not a reseller for any provider and have no incentive to prefer one. Selection is driven by data-residency constraints, task requirements, latency budget and cost at your volume, and we benchmark against your data rather than a leaderboard.

Yes. We deploy into client VPCs on AWS, Azure and GCP routinely, and can run entirely on open-weight models on your own hardware where nothing may leave the perimeter. There is a real capability trade-off with fully self-hosted open models on the hardest reasoning tasks, and we scope which parts of a system genuinely need that constraint rather than applying it uniformly.

No, and nobody does — be wary of anyone claiming otherwise. What good architecture does is make model error detectable and attributable: every answer cites the passage it came from, so an unsupported claim has no citation and a reviewer can spot it in seconds. That is the achievable and more useful goal.

With an evaluation set built in the first week — real inputs with human-verified correct outputs, scored automatically and run as a gate before every deploy. Without it, quality is anecdote. It is the single highest-leverage thing in an AI project and the most commonly skipped.

We pin model versions in production and put the model behind an interface, so a migration is a change with a regression gate rather than a rewrite. Run the eval suite against the new version, review the diff, migrate deliberately. Systems whose prompts are entangled with one specific model version are the ones that suffer here.

No. We hold no security certifications at this time, and we say so plainly rather than displaying badges we have not earned. We implement the controls those frameworks describe and document them per engagement, and we build systems that generate evidence for your own compliance obligations. If your procurement has a hard certification gate, we will not clear it — and we would rather you knew that on the first call.

Not on the enterprise API paths we deploy. We request zero-retention configurations where the provider offers them and document what was actually enabled in the architecture document rather than pointing at a general policy page. Provider terms change; we confirm against the current terms at the time of the build. Where you consume models through Bedrock, Vertex or Azure, data handling follows your existing agreement with that cloud provider.

As an authorisation problem rather than a filtering one. Content retrieved from documents, tickets or web pages is treated as untrusted data and can never authorise a tool call. Tools carry least privilege and destructive operations require confirmation. Filtering helps at the margins but cannot be the primary control when the attack surface is everything the system reads.

Yes, and we can work from your paper. Standard contractual clauses where a transfer requires them. Where a system runs entirely in your infrastructure and we never hold your data, we will say so rather than papering over a processing relationship that does not exist.

Barcelona, Spain. We work with clients across the EU and remotely, and travel for discovery workshops where being in the room genuinely helps — which it often does in the first week and rarely does afterwards.

A small senior team rather than a pyramid. That means the people on your first call are the people who build the system, and it also means we take on fewer projects at once. If we are at capacity we will tell you rather than staffing you with someone we just hired.

We publish reference architectures instead — the designs, the failure modes and what to measure — because they are more useful and because we will not publish client results we cannot evidence. Most client work is under NDA. The projects we can name are on our work page, each with what we built, what we did not, and a link to the live site; client results we cannot evidence stay unpublished.

That is a normal starting point and often a healthier one than arriving with a fixed solution. A discovery engagement exists precisely for this: assess what is feasible, what is valuable, and what should not be built. The output is written to stand alone and be usable by another vendor.