1. Home
  2. Technology & services

Technology & services

The stack we engineer on, and how we engage.

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.

Stack layers
Cloud · Data · Application · DevOps · Security · AI
Engagement models
Project · Pod · Managed · Advisory
Lifecycle
Discover → Design → Build → Verify → Operate
Operations
24×7 monitoring with defined service levels

01 / Technology stack

Six layers, chosen for operability.

We standardise deliberately. A shorter, deeper toolchain means faster onboarding, better automation and fewer unknown failure modes at 3am.

L.01

Cloud & platform

Landing zones, container platforms and the automation that keeps environments identical.

AWSAzureGoogle Cloud KubernetesTerraformHelm Argo CDDocker
L.02

Data & analytics

Ingestion, storage, modelling and presentation layers with governance attached from the start.

SnowflakeDatabricksMicrosoft Fabric BigQueryApache KafkaAirflow SparkPower BI
L.03

Application engineering

Server-side platforms, APIs and interfaces built for maintainability and accessibility.

.NETJava / Spring BootNode.js Python / FastAPIReactTypeScript PostgreSQLRedis
L.04

DevOps & SRE

Pipelines, observability and on-call practice — the difference between shipping and shipping safely.

GitHub ActionsGitLab CIAzure DevOps PrometheusGrafanaOpenTelemetry Elastic Stack
L.05

Security engineering

Identity, secrets, posture management and detection — implemented, tuned and evidenced.

Entra ID / OktaHashiCorp VaultCSPM & CWPP SAST / DAST / SCASIEMSOAR
L.06

AI & automation

Applied machine learning and language models, deployed with explicit data boundaries.

Managed LLM APIsRetrieval augmentationVector search MLflowFeature storesWorkflow automation

02 / Service catalogue

Defined services with defined outputs.

Indicative durations for a mid-sized enterprise scope. Every engagement is quoted against a written scope, and every one produces artefacts you keep.

Core service catalogue — indicative durations
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

Four commercial shapes. No hidden third parties.

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.

M.01

Project delivery — fixed scope

A defined outcome, a defined price and a defined date. Suited to assessments, landing zones, migrations and well-specified builds.

Best for
Clear requirements with a hard commercial boundary
You get
Written scope, acceptance criteria, fixed commercial terms
Change
Handled through a documented change-control process
M.02

Dedicated engineering pod

A named cross-functional team — architect, engineers, QA — working to your backlog with our delivery practices and your priorities.

Best for
Evolving products and multi-quarter roadmaps
You get
Named engineers, sprint cadence, monthly outcome reporting
Change
Re-prioritise the backlog at any sprint boundary
M.03

Managed services

We run the platform against agreed service levels, with a standing engineering allocation for improvement rather than pure ticket handling.

Best for
Production platforms needing 24×7 accountability
You get
SLOs, on-call rotation, monthly service review
Change
Improvement backlog agreed each month
M.04

Advisory retainer

Access to senior architects for design review, vendor evaluation, due diligence and second opinions — without a delivery commitment.

Best for
In-house teams that need independent challenge
You get
Scheduled review sessions and written recommendations
Change
Convert to delivery at any point, credited fairly

04 / Delivery lifecycle

Five stages, each with an artefact you keep.

Stages overlap in practice, but none of them is skipped. The artefact column is the part that matters six months later.

01

Discover

Stakeholder interviews, estate inventory, constraint mapping and success criteria agreed in writing.

Artefact: findings & scope

02

Design

Target architecture, non-functional requirements, platform decisions with recorded rationale and rejected options.

Artefact: architecture & ADRs

03

Build

Increment-based delivery with infrastructure as code, automated pipelines and environment parity from day one.

Artefact: code & pipelines

04

Verify

Functional, performance, resilience, accessibility and security testing — with results published, not summarised.

Artefact: test evidence

05

Operate

Service levels, observability, on-call and a standing improvement backlog — or a clean handover to your team.

Artefact: runbooks & SLOs

05 / Managed operations

Operations run as engineering, not as a queue.

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.

Availability target
99.95% for platform services, measured monthly
P1 response
15 minutes, 24×7, with a named engineer on the bridge
P1 restoration target
4 hours, with root-cause analysis within 5 working days
Patch cadence
Monthly baseline; critical vulnerabilities within 72 hours
Resilience testing
Quarterly failover and restore verification
Reporting
Monthly service review, quarterly roadmap review

Operations functions

24×7
O1

Monitoring & alerting

Metrics, logs, traces and synthetic journeys with tuned thresholds

O2

Incident management

Severity model, escalation paths, communications and post-incident review

O3

Problem management

Recurring causes tracked as engineering work with owners and dates

O4

Change & release

Peer-reviewed, automated, reversible changes with audit trail

O5

Security operations

Detection tuning, vulnerability management and response rehearsal

O6

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

The non-negotiables in every repository.

These apply whether the engagement is three weeks or three years. They are enforced in pipelines, not in a policy document nobody reads.

Code quality gates

Peer review on every change, linting and formatting enforced, coverage thresholds agreed per service and checked in CI.

Security in the pipeline

Dependency scanning, static and dynamic analysis, secret detection and signed build artefacts before anything reaches production.

Accessibility & performance

WCAG 2.2 AA as the baseline for user interfaces, with performance budgets tested in CI rather than measured after launch.

Documentation as code

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 alignment
ISO/IEC 27001SOC 2 TSC NIST CSFCIS Benchmarks OWASP ASVSITIL 4 service practices Cloud well-architected frameworksWCAG 2.2 AA India DPDP Act, 2023GDPR

We adopt a new technology when we can explain how it fails, who operates it, and what it replaces. Enthusiasm is not an architecture.

Vandorq engineering principle No. 7

07 / Innovation practice

A standing evaluation cycle, not a slide deck.

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.

Reference implementations

Landing zones, data platform blueprints and CI/CD templates that shorten delivery and standardise quality.

Applied AI review

Use-case assessment with explicit data-residency, retention and human-review boundaries defined up front.

Failure rehearsal

Controlled fault injection against reference workloads to validate runbooks before clients need them.

Cost modelling

Unit-economics models per architecture pattern, so estimates are based on measurements.

08 / Commercial & practical

Questions we are asked before signing.

Q1 How do you price work?

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.

Q2 Who owns the code and infrastructure definitions?

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.

Q3 Will you work alongside our existing vendors?

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.

Q4 What happens if we want to exit?

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.

Q5 How do you handle data protection during delivery?

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.

Q6 Can you augment our in-house team rather than replace it?

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

Put our architects in front of your hardest constraint.

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.