Trust Center
the answers before the questions

The client, entirely. It is a no vendor lock-in policy applied every time: standard, documented technologies, handover of access credentials, API documentation in Swagger/OAS and the repository. We do not hold back parts of the system as commercial leverage.

No. We select enterprise cloud services that contractually guarantee the opposite, in line with GDPR and SOC 2. Where data is particularly sensitive or the sector demands it, a private AI infrastructure is considered, on-premise included, so nothing leaves the client's perimeter.

Wherever it needs to. We are not tied to a single cloud: we work routinely with OVH, AWS, Hetzner, DigitalOcean, Seeweb, Aruba and Azure, and just as often on the client's own infrastructure, with Kubernetes or Linux machines (Debian and Ubuntu). The choice is made at the start based on your regulatory, contractual and budget constraints, not on our convenience: if the requirement is that data stays on your servers, we design for that.

It depends on the context and is decided together: credential-based authentication, Single Sign-On against the corporate identity provider, multi-factor authentication (MFA), and one-time OTP codes sent to the corporate email address. On enterprise web apps, session tokens live in HttpOnly cookies rather than localStorage, so an XSS attack cannot read them.

The model is that the client creates the accounts. We do not create standalone users on your environments: we ask to be authorised on accounts that already exist, or to be added to your working team with named users. The consequence is the one that matters to you: you can review or revoke our access at any time, without going through us and without the system breaking. This applies to infrastructure, backups and DevOps pipelines.

An LLM is never wired straight to a database. We build agentic systems with guardrails and strict data-schema validation, and for write or high-risk operations we use human-in-the-loop flows, where a person approves before the action takes effect. Automation reaches as far as the cost of a mistake stays acceptable.

Through AI observability: every agent operation leaves an immutable record of the context read, the data extracted, the reasoning steps followed and the token cost. It exists so that what happened can be reconstructed months later, which is what any audit asks for.

The code is already yours and already delivered, there is nothing to recover. It runs on widely used technologies another team can pick up, the data sits in standard databases you can export without going through us, and the business logic is not tied to a single model vendor. Continuity is a consequence of the architecture, not a contractual promise.

Backup, RTO and RPO have no standard value: they are sized against the damage an outage would cause in your case, and agreed before going to production. Alongside the backup we hand over documented restore procedures and the means to obtain copies of the backups and move them onto your own servers or machines. A backup only the supplier knows how to restore is not a backup, it is another point of dependency.

Yes, but not on every project: it makes sense on large-scale initiatives, where the financial investment and operational impact make continuity a risk worth covering formally. In those cases terms, escrow agent and release conditions are settled in the contract. It is worth saying, though, that escrow mainly protects clients whose supplier does not hand over the code: here the source is already yours and already in your hands from the first commit, so escrow covers a residual risk, not the main one.

Yes. Volcanic Minds carries professional indemnity insurance and a cyber policy, which covers damages and cyber attacks. It is a question that almost always comes from procurement or legal: policy details are provided on request during contract negotiation.

Release is the beginning, not the final delivery. We work with corrective and evolutionary maintenance contracts with explicit SLAs, and a clear line between bugs (under warranty) and new features. Training and handover to the client's team are part of it.

Through a transparent Change Request process: we assess the impact on time and cost together and decide whether to build now, replan or postpone. Nothing is implemented without the client's approval, and nothing is invoiced by surprise.

Yes, we design to WCAG 2.2 level AA: adequate contrast, full keyboard navigation, roles and states exposed to assistive technology. Accessibility enters the requirements at the start, because bolting it on at the end costs far more and works worse.

The payment split is flexible and calibrated on the complexity of the project and the clarity of the requirements.

Generally, for a standard project running around four months, we apply a milestone structure like this one:

Deposit: an upfront share from 25% (for long-standing clients we have worked with for years) up to 35% (for unusual projects, highly complex or with strongly evolving requirements).

Intermediate milestones: later payments are spread across the stages of the project. We always place a key milestone at the end of development, right before QA and testing begin.

Balance: paid on project close and final release.

We ask for your presence throughout the project, with regular meetings (roughly once a week) where the project and its progress are discussed and where either side raises issues or needs.

Then comes a pre-release QA phase that actively involves both sides for checks and reports. This phase genuinely matters and has to be done together.

It exists to take the surprise out of release, during which we run an exhaustive pass over the whole system. Once the ceremony is over we do not send the closing invoice straight away: we leave a few days for you to think it over behind closed doors, and only then issue the final invoice.

In the month that follows, our presence for fixing blocking issues and minor work is included.

Yes to both.

We are glad to show you a sample contract so you can see our transparency and attention to detail first hand. The text is flexible and we are open to changes justified by the specifics of the project.

On protecting information (NDA), we have our own template, fully bilateral and balanced. We are equally open to reviewing and signing the document your legal team proposes, provided it respects fairness and transparency and creates no asymmetry between the parties.

Since this is legal and confidential material, we share these documents right after a first introductory call.