Cloud & platform
Landing zones, container platforms and the automation that keeps environments identical.
Technology & services
No mystery about the technology or the commercial model. This page lists the platforms our engineers work in daily, the services we sell, the lifecycle we run, and the standards we hold ourselves to.
01 / Technology stack
We standardise deliberately. A shorter, deeper toolchain means faster onboarding, better automation and fewer unknown failure modes at 3am.
Landing zones, container platforms and the automation that keeps environments identical.
Ingestion, storage, modelling and presentation layers with governance attached from the start.
Server-side platforms, APIs and interfaces built for maintainability and accessibility.
Pipelines, observability and on-call practice — the difference between shipping and shipping safely.
Identity, secrets, posture management and detection — implemented, tuned and evidenced.
Applied machine learning and language models, deployed with explicit data boundaries.
02 / Service catalogue
Indicative durations for a mid-sized enterprise scope. Every engagement is quoted against a written scope, and every one produces artefacts you keep.
| Service | What it includes | Typical duration | Primary output |
|---|---|---|---|
| Cloud assessment & roadmap | Estate review, dependency mapping, TCO model, target architecture options | 2–4 weeks | Findings pack, roadmap, business case |
| Landing zone build | Account structure, identity, network segmentation, policy and cost guardrails | 3–6 weeks | Live platform plus infrastructure-as-code repository |
| Workload migration | Wave planning, rehost / replatform / refactor execution, cutover and validation | From 6 weeks | Migrated workloads, runbooks, rollback plans |
| Cloud & AI cost planning, investment and optimisation (short & long term) | Spend baselining, budget and forecast modelling, commitment strategy, rightsizing and an optimisation backlog | 2–6 weeks, then quarterly | Cost model, investment plan and optimisation backlog |
| Data platform build | Ingestion, layered storage, modelling, quality gates, catalogue and access control | 8–16 weeks | Governed platform and first data products |
| Product engineering pod | Discovery, incremental delivery, QA automation, release and observability | Ongoing | Shipped software, tests, architecture documentation |
| Security posture review | Control framework mapping, configuration review, prioritised remediation plan | 3–5 weeks | Risk register and remediation backlog |
| Hybrid and sovereign AI and AI security advisory | Hybrid and sovereign AI reference architecture, residency and control boundaries, model risk review, secure AI guardrails | 4–6 weeks | AI security posture report and target architecture |
| Detection engineering | SIEM use-case development, SOAR playbooks, alert tuning, monitoring onboarding | 6–10 weeks | Tuned detections and incident-response playbooks |
| Managed platform operations | Monitoring, patching, incident and problem management, continuous hardening | Ongoing | Monthly service and improvement report |
03 / Engagement models
The model should follow the problem, not the other way round. If your requirement is well understood, buy a fixed scope. If it will evolve, buy a team.
A defined outcome, a defined price and a defined date. Suited to assessments, landing zones, migrations and well-specified builds.
A named cross-functional team — architect, engineers, QA — working to your backlog with our delivery practices and your priorities.
We run the platform against agreed service levels, with a standing engineering allocation for improvement rather than pure ticket handling.
Access to senior architects for design review, vendor evaluation, due diligence and second opinions — without a delivery commitment.
04 / Delivery lifecycle
Stages overlap in practice, but none of them is skipped. The artefact column is the part that matters six months later.
01
Stakeholder interviews, estate inventory, constraint mapping and success criteria agreed in writing.
Artefact: findings & scope
02
Target architecture, non-functional requirements, platform decisions with recorded rationale and rejected options.
Artefact: architecture & ADRs
03
Increment-based delivery with infrastructure as code, automated pipelines and environment parity from day one.
Artefact: code & pipelines
04
Functional, performance, resilience, accessibility and security testing — with results published, not summarised.
Artefact: test evidence
05
Service levels, observability, on-call and a standing improvement backlog — or a clean handover to your team.
Artefact: runbooks & SLOs
05 / Managed operations
A ticket queue tells you what broke. An engineering practice removes the reason it broke. Our managed service reserves a fixed share of every month for permanent fixes, drawn from problem analysis rather than a wish list.
You get named engineers who know your estate, transparent service-level reporting, and a monthly review where the improvement backlog is agreed with you.
Operations functions
24×7Monitoring & alerting
Metrics, logs, traces and synthetic journeys with tuned thresholds
Incident management
Severity model, escalation paths, communications and post-incident review
Problem management
Recurring causes tracked as engineering work with owners and dates
Change & release
Peer-reviewed, automated, reversible changes with audit trail
Security operations
Detection tuning, vulnerability management and response rehearsal
Cost & capacity
Consumption review, right-sizing and forecast against budget
15m
Target first response on a priority-one incident
4h
Target restoration window for priority-one incidents
06 / Engineering standards
These apply whether the engagement is three weeks or three years. They are enforced in pipelines, not in a policy document nobody reads.
Peer review on every change, linting and formatting enforced, coverage thresholds agreed per service and checked in CI.
Dependency scanning, static and dynamic analysis, secret detection and signed build artefacts before anything reaches production.
WCAG 2.2 AA as the baseline for user interfaces, with performance budgets tested in CI rather than measured after launch.
Architecture decision records, runbooks and diagrams live beside the code and are reviewed in the same pull request.
Frameworks referenced in our delivery standards
Practice alignmentWe adopt a new technology when we can explain how it fails, who operates it, and what it replaces. Enthusiasm is not an architecture.
07 / Innovation practice
Our engineering group maintains reference workloads used to evaluate new platform services, AI tooling and security capabilities. Anything that reaches a client roadmap has already been run against them.
Landing zones, data platform blueprints and CI/CD templates that shorten delivery and standardise quality.
Use-case assessment with explicit data-residency, retention and human-review boundaries defined up front.
Controlled fault injection against reference workloads to validate runbooks before clients need them.
Unit-economics models per architecture pattern, so estimates are based on measurements.
08 / Commercial & practical
Assessments and clearly specified builds are quoted as fixed price against a written scope. Evolving work is priced as a dedicated pod with a monthly rate per named role. Managed services are priced on the estate under management plus a reserved engineering allocation. In every case you receive a breakdown by component and the assumptions behind it, so you can challenge the model rather than just the number.
You do, from the first commit. Work is delivered into repositories you control, under your accounts and your credentials. We do not retain private forks, and we do not build deliberate dependencies on Vandorq-hosted tooling. Third-party licences, where any are required, are disclosed in the proposal.
Regularly. We are often engaged as the design authority across a mixed supplier landscape. We will document interfaces and responsibilities clearly, raise conflicts early, and provide an honest assessment of another party's work when asked — in writing, and with evidence.
Every managed engagement includes an exit plan from the start: access inventory, runbook completeness checklist, knowledge-transfer sessions and a defined handover period. We would rather leave cleanly and be re-engaged later than hold a client through operational dependency.
Production data is not copied into development environments. Where realistic test data is required we generate synthetic or masked datasets. Access is least-privilege and time-bound, engineers work through logged access paths, and data-residency requirements are agreed before any environment is created.
That is the most common shape of our long engagements. Our engineers work in your repositories, your ceremonies and your review process, with an agreed split of ownership. Your team sits in our design reviews from day one, which is also how the knowledge transfer happens.
Next step
Bring the requirement, the legacy system, or the audit finding. We will tell you what we would do, what it would cost, and what we would not attempt.