Platform engineering
Two stacks. One precision standard.
Calvrix is a platform-engineering practice. Two practices cover the architecture and operations of long-running enterprise platforms, .NET / Azure and cloud-native, without the seams that make most vendors fail at handoff.
.NET / Microsoft enterprise stack.
Modern .NET, Entity Framework Core, Azure-native infrastructure, legacy modernisation, enterprise commerce, financial workflows, audit-grade correctness.
Cloud-native, multi-cloud, hands-on.
Kubernetes on AKS and EKS, Terraform, CI/CD, containerisation, observability, serverless workloads, security posture, multi-cloud operations.
What the platform layer covers
The load-bearing layer of an enterprise's operational stack.
The definition
What platform engineering actually is.
Platform engineering is the architecture, build, and ongoing operations of the infrastructure layer beneath revenue-critical applications. It is not a sprint to deliver one feature. It is not a cloud-migration project that hands the running system back to an under-resourced internal team and walks away. It is the discipline of owning the substrate the business actually depends on, and operating it to a written standard, indefinitely.
In practice the work is a continuous loop: design decisions land as ADRs; changes ship through reviewed pipelines with explicit rollback; the platform is observable enough that the on-call rotation can act on signals rather than guesses; post-incident reviews are published, signed off, and feed the next iteration of the operating standard. The platform improves while it runs.
Adjacent categories Calvrix is not. A cloud reseller sells licences and takes margin on consumption. A staffing agency places engineers and bills by the hour. A digital agency builds an application and hands it over. A DevOps consultancy installs pipelines and disappears. None of those are platform engineering as Calvrix defines it; each of them describes a different shape of work and a different commercial model. The work Calvrix does is to engineer the platform layer and stay accountable for its operation.
See the comparison table for how Calvrix sits against each of the above explicitly.
Two practices · one operating standard
Two practices. Two depths. One standard.
The two-practice split is not specialisation theatre. It is how the work is genuinely divided in the senior engineering market: Microsoft-stack enterprises operate under different constraints (compliance posture, integration with on-prem identity, .NET ecosystem maturity, Azure-native investment) than cloud-native shops (developer-experience-led, multi-cloud-by-choice, Kubernetes-substrated, GitOps-default). Calvrix runs both, and holds them to the same operating standard so an engagement reads the same regardless of which practice owns it.
.NET, Azure, audit-grade systems where money is the record.
Long-running .NET (Framework 4.8 maintained, .NET 10 modernised), Entity Framework Core, Azure App Service / Functions / SQL / Key Vault / Service Bus / Application Insights. Multi-storefront commerce, multi-gateway payments, settlement-grade ledgers. Compliance-aware: IAM, secrets, network, observability designed for audit, not retrofitted for it.
Kubernetes, Terraform, GitHub Actions, on AWS and Azure.
Production Kubernetes on AKS and EKS, declared in code (Terraform), shipped through reviewed CI/CD (GitHub Actions), observed through OpenTelemetry, with FinOps as a first-class signal. Multi-cloud only where the business stage genuinely needs it; otherwise the simplest viable substrate. Cost attribution per workload.
Engagements that span both practices are common: most modernisation work touches both the Microsoft surface and the cloud-native substrate. The handoff between practices is internal: the customer sees one engagement, one operating standard, one accountable senior owner.
The operating standard
The standard the on-call rotation actually follows.
Brand statements are cheap; the operating standard is what keeps a platform alive. Calvrix runs to a written set of practices that apply across both technology stacks and every engagement size.
ADRs for every significant decision.
Architecture Decision Records are the artefact every engineering choice produces. They name the context, the options considered, the call made, and what would change if the trade-offs flip. Decisions must survive the people who made them: that requires writing them down.
Runbooks for every recurring operation.
If it happens more than once, it gets a runbook. The runbook is the source of truth, not tribal knowledge. New engineers join an on-call rotation and operate the platform from day one, not from week three after they have shadowed enough incidents.
Observability before launch.
Logs, metrics, traces, dashboards, and the SLOs that anchor them: built before the platform takes its first live request. Not a sprint after the first incident. If you cannot see the platform behave, you cannot operate it.
Reviewed changes with explicit rollback.
Every change has a named approver, an environment-parity path through dev → stage → prod, and a rollback that has been rehearsed. Any change that cannot be rolled back gets a written ADR documenting why before it ships.
Post-incident reviews: published, signed off.
Incidents are not the system failing; they are the system telling you what to fix. Reviews are blameless, public to the customer's engineering team, signed off by the named senior owner, and feed back into the operating standard.
FinOps as a first-class signal.
Cost is attributed per workload, per environment, per customer. Cost surprises are operational failures. The FinOps review cadence is part of the engagement contract, not a quarterly afterthought.
See the full engineering practice page for how each principle plays out in delivery.
The category we refuse
Five refusals. Each one defines what Calvrix is by what it is not.
The brand is built on what it refuses as much as on what it ships. The refusals below are not marketing copy. They are operational rules. The engagement contract is shaped by them and the engineering work is constrained by them.
The decision aid
When platform engineering matters, and when it does not.
Platform engineering is an investment with a real operating cost. It is the right call when the platform is load-bearing on revenue, regulated workflows, or scale that has outgrown casual engineering decisions. It is the wrong call when a prototype just needs to ship.
| Signal | Platform engineering fits | Platform engineering is overkill | |
|---|---|---|---|
| Revenue exposure | Platform downtime costs material revenue per hour | Single-team product, pre-revenue or low single-digit MRR | |
| Regulatory posture | Audit, compliance, data-residency, settlement, or PCI scope | No regulatory surface beyond standard data protection | |
| Platform lifetime | Multi-year operating horizon: system outlives the team | Disposable prototype or 12-month experiment | |
| Operational ownership | On-call rotation exists or needs to exist | No production on-call expectation | |
| Team stability | Engineering team turnover means the platform needs to outlive memory | Founding team will own the system for the foreseeable future | |
| Vendor lock-in cost | Single-cloud lock-in carries real strategic risk | Lock-in is a non-issue at current scale |
Three or more rows in the left column is the signal Calvrix fits. Less than that, and you may not yet need a platform-engineering engagement, and we will tell you so.
Engineering writing
The writing the practice produces.
The same discipline that produces ADRs and post-incident reviews produces external writing too. Each post below feeds back into the operating standard the practice runs to.
How engagement works
Senior retainer. Scoped outcome. Sized to the system, not the calendar.
Engagements at Calvrix are sized to the risk in the platform and the stage of the business, not to a billing rate. We do not staff-augment, we do not day-rate, and we do not bill margin on cloud spend. Every engagement carries a named senior owner and a defined operating standard from day one.
- How it starts. A direct technical conversation. Send your system context to [email protected]: architecture, scale, the failure modes you actually worry about. We respond within two working days with whether the problem fits our level of work.
- What we own. Architecture, build, and ongoing operations. Documentation as a deliverable, not a side-effect. ADRs for every significant decision and a runbook for every recurring task.
- How it is priced. Senior retainer plus a scoped outcome, with reversibility built into every milestone. Pricing is anchored to the engagement, not the consumption.
- What we will not do. Staff augmentation. Day-rate placement. Discovery-call funnels. Cloud-margin billing. Open-ended scopes with no defined success criteria.
// start the conversation · [email protected]
Frequently asked
What buyers ask before engaging.
Platform engineering sounds like a rebrand of what our DevOps contractors already do. What is the difference?
The architecture, build, and ongoing operations of the infrastructure layer beneath revenue-critical applications, not a sprint to deliver one feature. We own the platform end-to-end: design, observability, change control, post-incident reviews, and the operating standard the on-call rotation follows.
We already have a reseller and a staffing agency on the panel. Where does Calvrix fit?
A reseller sells licences and takes margin on consumption. A staffing agency places engineers and bills by the hour. Calvrix is neither. We engage on a defined engineering outcome with our own delivery team, our own engineering standard, and full ownership of the platform we run.
Our sector is fairly specific. Have you actually worked in it?
Commerce, payments, financial workflows, regulated SaaS, and long-running Microsoft-stack enterprise systems. The pattern is the same across all of them: revenue-critical workloads where downtime is expensive and where casual engineering decisions compound into long-term cost.
We would rather bring engineers in on a day rate. Can you work that way?
A defined engagement with a delivery team, a scoped outcome, and an explicit operating standard. We do not do staff augmentation and we do not do day-rate placement. Each engagement is sized to the system risk and the business stage.
We are not in the UK. Does that make working with you difficult?
Calvrix Ltd is registered in Scotland. We work across UTC+0 and UTC+1 and accept work for UK, EU, and US customers. On-call rotations match the customer time zone or the platform-criticality window, whichever is more restrictive.
Procurement will want a DPA and an NDA before we can start. Is that going to be slow?
No. Where an engagement requires Calvrix to process personal data, a data processing agreement is signed before that work starts. NDA and data-residency clauses are familiar territory, and we redline collaboratively rather than queue them with lawyers for a fortnight.