Our approach
Considered from
the first conversation.
Good infrastructure starts with understanding. We take the time to define the right perimeter, the right tools and the right way to look after them.
01 / Discovery & audit
Understand.
We start with the work your firm actually does: the decisions, documents, relationships and routines that matter. We map where information lives, who needs it, and which obligations shape its use.
That includes the practical environment: existing IT support, network boundaries, available power, acoustic requirements, backup arrangements and business continuity.
What you receive
An agreed brief, data map, priorities and initial risk assessment.
02 / Design & architecture
Architect.
We translate the brief into a clear system design. Identity and document permissions come first. Model selection, hardware sizing, hosting and public-facing design follow the requirements they need to serve.
Together, we agree what remains local, what may connect externally, who can administer the system, and how changes will be authorised. Your legal and compliance advisers remain part of the decision process.
What you receive
A documented architecture, access model, delivery scope and acceptance criteria.
03 / Build & deployment
Establish.
We configure and test the environment before introducing it into daily work. Sensitive client archives are indexed within the agreed client environment; access controls are verified with representative roles.
AI responses are evaluated against approved examples. Website and portal work follows its own test and release process. We train the people who will use and maintain each system, then complete a documented handover.
What you receive
A tested deployment, user guidance, operational documentation and recovery plan.
04 / Ongoing stewardship
Steward.
Private infrastructure needs active care. An ongoing engagement can cover security updates, model reviews, document indexing, access changes, backup checks and improvements to your digital presence.
For isolated deployments, maintenance follows an agreed offline transfer process. The engagement defines responsibilities, visit frequency, support windows and incident escalation before service begins.
What you receive
A maintenance schedule, change history and regular review of the system’s usefulness.
A first engagement,
defined.
A first engagement has a fixed scope and a written end point. It might cover one knowledge workflow, one review of the existing environment, or one institutional website. Before work starts, we agree three things in writing.
- The outputs. For example a brief and data map, an architecture record, a tested deployment, user guidance and a recovery runbook, as the scope requires.
- The acceptance tests. They vary by project. Representative users reach what their role allows and nothing more. Sample questions return answers with their sources. A backup restores. The documentation matches what was built.
- The owners. Your firm names the people who run the tests and sign them off, and the people who will own each system after handover.
Work that fails a test is corrected before handover. The engagement closes with a documented handover. Anything outside the scope becomes a separate written decision.
A few practical questions.
Can we begin with one part of the firm?
Yes. A focused first engagement can establish one private knowledge workflow, review the existing environment, or improve your institutional website. We define a useful, testable scope before expanding.
Do we need to replace our existing IT provider?
Not necessarily. The architecture can be developed alongside your internal team and existing advisers. Responsibilities for identity, networks, hosting, updates and incident response are agreed explicitly.
Is every deployment fully air-gapped?
No. On-premises, network-isolated and physically air-gapped environments address different needs. The right design depends on the information, workflows and operating constraints involved. We agree and document the boundary rather than apply the same label to every deployment.
What happens after delivery?
You receive an agreed handover and operational documentation. Ongoing stewardship can be defined around maintenance, updates, user support and periodic reviews. Response times and service commitments are set in the engagement, not assumed.
Can you guarantee regulatory compliance?
Technology can support your obligations through access controls, audit trails, retention and security. Compliance also depends on your firm’s purposes, policies and conduct. We work with your legal and compliance advisers to translate those requirements into the architecture.
Who owns the system at the end?
We design for your firm to own its data, indexes, backups and configuration, with accounts, domains and subscriptions in its name where the vendor allows. Administrator and recovery credentials go to people you name. The engagement records vendor licence terms, hardware ownership and any access Desgarde keeps for stewardship.
Can we leave, or change provider?
Yes. We design for exit from the start: open formats where possible, exportable data, configuration kept as readable files, and an architecture record that names each third-party component. The engagement defines what you receive at exit and how our remaining access is closed.
How can we judge the work before committing further?
We do not publish client case studies. The evidence comes from the engagement itself: written acceptance criteria, a sample evaluation against questions your people choose, and a recovery test where the system holds data. Where it helps, a demonstration can run on synthetic material or on documents you approve and sanitise. You can test each output with your own advisers.