Capabilities
What we actually do, in detail.
Six practices, described the way we would describe them in a scoping call: what is in them, what an engagement looks like, and what is in your hands when we leave.
On this page
Six practices
Start where the problem is.
Most engagements draw on two or three of these at once — a migration that is really an identity project, a reporting stack that is really a data-ownership problem. Read the one that matches the symptom and we will tell you if it is actually something else.
Practice
Cloud & platform
Cloud Infrastructure & Platform Engineering
Most cloud estates are not badly built. They are unbuilt — assembled by hand, one console click at a time, by people who were busy.
The symptom is usually the bill, but the cause is that nobody can rebuild the environment from source. Accounts were opened as they were needed, access was granted as it was asked for, and the staging environment has drifted so far from production that testing there tells you very little. We fix the operating model first: an account structure with policy behind it, a network you can draw from memory, and everything expressed as code that runs in your pipeline rather than on someone's laptop.
What is included
-
Landing zones and account structure
Multi-account or multi-subscription topology with guardrails that are enforced rather than documented — service control policies or Azure Policy, centralised logging into an account nobody can write to, and a break-glass path that has been tested at least once.
-
Network and connectivity design
Addressing plan that leaves room for the next five years, private subnets with controlled egress, transit routing between regions and on-premises, split-horizon DNS, and site-to-site or client VPN. The default VPC gets deleted.
-
Kubernetes and runtime platforms
EKS, AKS or GKE where the workload justifies it; ECS, Cloud Run or plain autoscaling groups where it does not. Admission control, workload identity, secret management, ingress with mTLS between services, and cluster upgrades on a calendar rather than in a panic.
-
Infrastructure as code and delivery pipelines
Terraform or OpenTofu modules with state isolated per environment, a plan posted on every pull request, drift detection running nightly, and promotion between environments that changes one variable file rather than one engineer's memory.
-
Cost governance and right-sizing
A tagging schema enforced at provisioning time, per-team budgets with alarms that reach a human, commitment coverage modelled against real usage, and a monthly variance review. This is part of the build, not a cleanup project you fund in year two.
-
Migration and cutover
Dependency mapping from live traffic rather than from a spreadsheet, waves sequenced so the riskiest move is not the first, replication and dry runs, and a cutover plan with a rollback that has been rehearsed against a stopwatch.
A typical engagement
Two to four weeks of assay, then eight to sixteen weeks of build, with two engineers and a part-time architect. The landing zone lands around week six. The first workload migrates around week nine — deliberately not the most important one. We migrate the first two with your team watching, and your team migrates the third with us reviewing the pull requests. If that does not work, the engagement is not finished, whatever the plan says.
What you are left with
An infrastructure repository in your organisation.
Modules, per-environment state configuration, the pipeline definition, and a README that begins with the commands to run. Every commit is authored under your accounts from day one.
Architecture decision records, one per material choice.
What was decided, what else was considered, why the alternative was rejected, and what would have to change for the decision to be revisited.
Runbooks for the ten things that actually happen.
Scaling a service, rotating a credential, restoring from backup, draining a node, using break-glass access. Written to be followed at three in the morning by someone who did not build it.
A cost baseline and a network diagram that match reality.
The diagram is generated from state, not drawn in a slide tool, so it stays true. The baseline dashboard ships with budget alarms already wired to your alerting channel.
Practice
Cybersecurity
Cybersecurity & Compliance
Security fails at the joins — the leftover admin account, the log that was never shipped anywhere, the exception granted in a hurry three years ago and never revisited.
Two things go wrong in most estates. Identity has sprawled: people have standing administrative rights they no longer need, and service accounts exist that nobody will admit to owning. And findings have accumulated without owners — a report arrives, everyone agrees it is serious, and nothing has a name and a date attached to it. We work identity-first, then close the gaps ourselves rather than handing you a spreadsheet and an invoice.
What is included
-
Identity and access
Consolidation onto a single identity provider, joiner–mover–leaver automation that actually removes access, standing administrative rights replaced with time-bound elevation, and an inventory of every service account with a named human owner.
-
Endpoint and network hardening
Baseline configuration enforced by policy, full-disk encryption verified rather than assumed, endpoint detection coverage measured against the asset list, segmentation between corporate and production networks, and egress filtering where it is practical.
-
Logging, detection and response
A decision about what is shipped where and kept for how long, driven by your obligations rather than by a vendor's storage tier. Detections written against your environment instead of a default rule pack, and a playbook for every alert that is allowed to wake someone.
-
Vulnerability and patch management
Asset inventory first, because you cannot patch what nobody owns. Then remediation targets by severity, an exception register in which every entry carries an expiry date, and reporting that shows the trend rather than the total.
-
Compliance readiness
ISO 27001, SOC 2 Type II, NIST CSF and Cyber Essentials Plus. Gap assessment mapped control by control, evidence collection automated wherever the control allows it, and support through the audit itself — including the questions the auditor is going to ask that the checklist does not.
-
Incident response readiness
Contact tree, legal and communications path, forensic capture procedure, out-of-band communications for when the primary channel is the thing that is compromised, and a tabletop exercise run against a scenario drawn from your own architecture.
A typical engagement
A posture assessment runs three to five weeks at a fixed fee and produces a prioritised register you own regardless of what follows. Remediation is usually three to six months alongside your team. Certification is longer and we will say so plainly: nine to twelve months to a first ISO 27001 certificate from a standing start, because the standard requires a management system with a history, not a folder of policies. Anyone quoting three months is selling you documents.
What you are left with
A risk register with names and dates in it.
Each finding has an owner who has agreed to be the owner, a target date, and a stated business consequence. Items we closed during the engagement are marked closed with the evidence attached.
Detections and playbooks committed as code.
Rules, thresholds and response steps live in your repository and deploy to your SIEM through your pipeline. Nothing important is held in a console someone configured by hand.
A control matrix and a working evidence pipeline.
Every control mapped to the standard, to the system that implements it, and to the automated job that collects the proof. The next audit cycle should cost you a fraction of the first.
The tabletop report, including what went badly.
Written honestly. A rehearsal that everyone passes was not a rehearsal, and the useful output is the list of things nobody could find under pressure.
Practice
Software
Custom Software Development
Off-the-shelf software fits the average of an industry. Some of your process is the reason you win, and it will never be the average.
We build where the fit is genuinely poor: the workflow held together by three spreadsheets and one long-serving employee, the integration layer between systems that were never meant to speak, the internal tool that would save forty hours a week and has been on the roadmap for two years. We will also tell you when a configured product would serve you better than anything we could write, which happens more often than a development firm usually admits.
What is included
-
Discovery and domain modelling
Time spent beside the people doing the work, not only with the people describing it. What comes out is a shared model with agreed names for things — the artefact everything else hangs off, and the one most projects skip.
-
Web applications and internal tools
TypeScript and React, or server-rendered where that is simpler, on Node, Python or .NET. We choose the stack your team can hire for and maintain, not the one that is interesting this year.
-
APIs and integration
Versioned contracts written before the implementation, idempotent writes, sensible pagination and error semantics, event-driven integration where the coupling justifies it, and adapters for the ERP or CRM that is never going to change.
-
Legacy modernisation
Characterisation tests around the existing behaviour first, then traffic routed module by module to the replacement. Big-bang rewrites fail for a well-documented reason and we will not propose one.
-
Quality engineering
Typed codebases, tests written at the level that catches real regressions rather than at the level that inflates a coverage number, continuous integration that blocks the merge, and a preview environment per pull request.
-
Mobile
React Native when the application is mostly screens and data, native when it is mostly hardware, offline behaviour or background work. We will say which one yours is before you commit.
A typical engagement
Four to eight weeks of discovery ending in a working prototype and a costed plan, then a first production release three to six months later with a team of two to four. Two-week iterations, a demo every second Thursday against running software rather than slides, and a release to real users well before the scope is complete. If your engineers are going to own it afterwards, they pair with ours from the first iteration, not from the handover.
What you are left with
Repositories in your organisation, under your licence.
Application code, infrastructure definitions and pipeline configuration. No Aviaurum runtime, no hosted component you have to keep paying us for in order to keep running what you paid for.
A docs folder that opens with the domain model.
The model, the decision records, the data schema, and the integration contracts. Written for the engineer who joins two years from now with no access to anyone who was there.
A test suite and a pipeline that gate the merge.
Including the tests that describe the awkward business rules — the ones that look wrong until you learn why they exist. Those get comments explaining the why.
An onboarding document timed against a real newcomer.
We give it to an engineer who has never seen the project and measure how long it takes them to run it locally and ship a trivial change. Whatever they stumble on gets fixed before handover.
Practice
Data & AI
Data Engineering & Applied AI
Two failures dominate: the warehouse nobody trusts, and the AI pilot that demonstrated beautifully and never reached production.
They have the same root. Nobody agreed what a number means, and nobody agreed how the system would be judged before it was built. We start by writing down the definition and the evaluation — what counts as an active customer, what accuracy would make this worth running — and only then build the pipeline or the model. It is slower for the first fortnight and considerably faster after that.
What is included
-
Warehouse and modelling
Snowflake, BigQuery, Databricks or plain Postgres where the volume does not justify more. Transformations in dbt or SQLMesh with tests on the models themselves, so a broken assumption fails the build instead of quietly reaching a dashboard.
-
Ingestion and pipelines
Change data capture from operational databases, connectors for third-party sources, a backfill strategy decided before the first load, reruns that are safe to repeat, and freshness targets that alert someone when they are missed.
-
Governance and data quality
Column-level lineage so an outage in one source names the dashboards it affects, personal data classified and access restricted at row level, and a data dictionary maintained by the domain owners rather than by whoever built the table.
-
Reporting and BI
A small number of certified dashboards, each with a named owner and a stated refresh, replacing the four hundred orphaned reports that currently make every meeting an argument about whose figure is right.
-
Retrieval systems over your own documents
Chunking, embedding and retrieval tuned against your corpus, with the evaluation set built before the system. Answers cite their sources, and the system is permitted to say it does not know — which is the behaviour that makes it usable in a regulated setting.
-
Forecasting, anomaly detection and classification
A simple statistical baseline first, always. We reach for anything larger only once it beats that baseline on a holdout period, and we report the comparison whichever way it goes.
-
Evaluation and operations
An offline evaluation suite that runs in continuous integration, a human review loop for the cases that matter, cost and latency budgets per request, and a rollback that does not require a deployment.
A typical engagement
A warehouse foundation is eight to twelve weeks: three or four source systems modelled properly and one reporting area moved onto them, not everything at once. Applied AI work runs as a four to six week evaluation-first pilot with a fixed fee and a genuine go or no-go at the end. We have recommended no-go on roughly one in four, and the written reasoning is the deliverable in that case — it is usually worth more than the model would have been.
What you are left with
A transformation project, tested and documented.
Models, tests, lineage and generated documentation in your repository, running on your schedule in your warehouse, with the sources and the freshness expectations declared.
An evaluation harness with a scored baseline.
The dataset, the metrics, the current score and the runner. When someone proposes a change six months from now, you can measure it instead of debating it.
A data dictionary and a short list of owned dashboards.
Each definition attached to the person who is accountable for it. Retired reports are listed too, with what replaced them, so the cleanup does not quietly reverse.
A written record of what was tried and rejected.
Including the approaches that did not work and the reason. This is the document that stops your organisation paying to rediscover the same dead end in two years.
Practice
Strategy
Technology Strategy & Advisory
Sometimes the question is not what to build. It is whether to build at all, with whom, and in what order.
This is the practice people call when a decision has to be defended rather than merely made: a board paper that will be read sceptically, an acquisition where the technology is either the asset or the liability, an estate that has quietly outgrown the team running it. Our advice is evidence-led — we read the repositories, the cloud bill and the incident history before we read the strategy deck, because the first three describe what the organisation actually does.
What is included
-
Architecture and estate review
Grounded in artefacts: source control history, deployment frequency, the incident log, the licence schedule and the actual spend. Interviews confirm what the evidence suggests; they do not substitute for it.
-
Build, buy or partner analysis
Five-year total cost including the people required to run each option, the switching cost at the end, and the option you did not ask us to evaluate. Assumptions are visible and can be changed by whoever disagrees with them.
-
Vendor selection
Requirements weighted and signed off before any demonstration, structured scoring against them, a proof of concept on your data where the contract is large enough to justify one, and reference calls with customers the vendor did not nominate.
-
Technical due diligence
For acquirers and for companies preparing to be acquired. Code and architecture quality, key-person concentration, open-source licence and intellectual property hygiene, security posture, and a costed estimate of integration or remediation.
-
Roadmaps and costing
Sequenced by dependency and risk, costed in real currency with named roles and durations, and structured around decision gates so the plan can be stopped or redirected without being abandoned.
-
Fractional CTO and interim leadership
One or two days a week: hiring and interview design, engineering standards, vendor management, and board reporting in language a board can act on. A fixed term with a stated intention to hand over to a permanent hire.
A typical engagement
Two to six weeks at a fixed fee against a fixed date, with a principal and one engineer. Due diligence is usually ten working days and we work to the deal calendar. Fractional leadership runs in months with thirty days' notice on either side, and we will tell you when you have outgrown the arrangement rather than waiting for you to notice.
What you are left with
A written report addressed to the decision maker.
Recommendation on the first page, evidence behind it, and an appendix for the people who will have to implement it. Short enough to be read in full before the meeting.
The financial model, as a spreadsheet you keep.
Assumptions in labelled cells rather than hard-coded into formulas, so your finance team can rerun it with their own numbers and see where the conclusion changes.
A risk register and a decision log.
What we recommended, what you decided, and where the two differ. The differences are recorded without editorial, because in three years the record is what matters.
A debrief with the people who have to execute it.
Scheduled as part of the engagement, not offered afterwards. A strategy that only the sponsor understands has not been delivered.
Practice
Managed services
Managed Services & 24/7 Operations
We take the pager — for the environments we built and for the ones you already have. Managed services goes wrong when it becomes ticket closing instead of problem removal.
The measure we hold ourselves to is whether the same ticket comes back. A provider paid by volume has no reason to make the volume fall; we are paid for the environment, so a recurring incident costs us and gets engineered out. That is also why we will not accept a handover of an estate we have not documented first — taking the pager for something nobody understands is how three in the morning becomes everyone's problem.
What is included
-
Monitoring and observability
Service level objectives agreed with you rather than imposed, alerts that each point to a runbook, and a standing rule that any alert firing without an action attached gets fixed or deleted within the month.
-
On-call and escalation
Follow-the-sun cover with a fifteen-minute response target for critical incidents, a named escalation engineer who knows your estate, and a telephone number. Escalation is a call, not a form.
-
Backup and disaster recovery
Recovery targets agreed and then tested rather than asserted. Restores are performed on a schedule into an isolated environment, and the test report — including the failures — comes to you.
-
Patch and lifecycle management
Agreed maintenance windows, staged rollout with a rollback prepared before the change, emergency patching for what genuinely warrants it, and an end-of-life register so a support expiry is never a surprise.
-
Service desk
First and second line for end users against published response targets, in your ticketing system rather than ours, with a monthly analysis of what people keep asking for and what would stop them needing to.
-
Problem management
Every critical incident gets a written review within five working days: what happened, what was missed, what changes and who owns it. Recurring tickets generate an engineering task, not a canned reply.
A typical engagement
A twelve-month term with sixty days' exit for convenience — we would rather earn the renewal than hold you to a notice period. Before any of it starts there is a four to six week transition: shadowing your team, capturing runbooks, moving monitoring onto agreed objectives. We do not accept the pager until that is finished. Afterwards there is a monthly service review with a person and a quarterly one with the numbers, including the ones that make us look bad.
What you are left with
Runbooks in your repository, from week one.
Written during transition, updated every time they are used and found wanting. They are yours throughout the contract, not handed over at the end of it.
Monitoring, alerts and objectives defined as code.
In your tooling and your accounts. If you move to another provider or bring it in-house, the observability layer goes with you and keeps working.
The full incident and problem history, exported.
Every review, every root cause, every change made in response. The history is where the value of a long operations relationship actually accumulates.
Restore evidence and a documented exit.
Dated proof that recovery works, and an offboarding plan written at the start of the contract rather than negotiated at the end of it. Handover is a scheduled deliverable with a date on it.