The bill tells you what you actually built.
Not the architecture diagram, not the README — the invoice. It records every instance somebody started for an afternoon, every environment that outlived its demo, every gigabyte that left the region because nobody modelled egress. A cloud bill is the most honest document a company owns, and almost nobody reads it line by line.
We do that read, and then we do the thing that makes it stick: put the infrastructure into code in your repository, take the person out of the deploy path, and write the runbook for whoever inherits it. Kubernetes appears here only where a workload has earned a cluster — most have not, and we say so before the invoice does.
We have operated a trading back office through years of change for a client in a long-running relationship, on a platform serving 8,000+ monthly active users that has to be up during market hours. Running a system for years is a different discipline from launching one.
The Cloudflare claim on this page is checkable in about ten seconds: Turnstile guards the forms on this site, and it challenges on submit rather than on load, so a reader who never touches a form is never challenged.
There is no uptime figure, SLA percentage, incident-response time or cost-saving percentage anywhere on this page. None has been cleared for publication, and a percentage without workings is the easiest number in this industry to invent. The map below is schematic and says so.
30 minutes, working session. Show us how a change reaches production today and last month’s invoice; you leave with a one-page read either way. Nobody follows up more than once.
Cloud problems are ownership problems wearing technical costumes
Every one of these arrives at our door described as an infrastructure fault. None of them is. They are all the same fault: something important has no name against it, and the console is the last place that becomes visible.
Releasing is a ceremony
A checklist in a document, a manual smoke test, one person who runs it, and an unwritten rule about Fridays. So the batch grows, the risk per release grows with it, and the team becomes slow and frightened at the same time — which is the expensive combination.
One person knows how it was built
Servers configured by hand over three years, nothing written down, and annual leave coming up. Everybody knows the bus factor is one, including that person, who has quietly stopped taking holidays. The fix is not a wiki page; it is putting the configuration somewhere a second person can read and change it safely.
The bill grows and nobody can explain it
Idle capacity, oversized instances, three forgotten environments, storage nobody tiers and egress nobody modelled. Finance asks for a breakdown by team or by product, and there is no tagging to build one from — so the honest answer is that most of the invoice is unattributable.
Staging does not resemble production
Different instance sizes, different data volumes, a queue that never backs up. So the bug appears only in production and the fix is tested in an environment that cannot reproduce it. Everyone on the team knows this is the problem; nobody has the free week to fix it.
Kubernetes arrived for a product that did not need it
Now there is a cluster, an upgrade cadence, a set of controllers and a YAML surface area, all owned by an application team that wanted to ship features. The technology is not the mistake. The absence of a full-time owner for it is.
The backup has never been restored
It runs nightly. It reports success. Nobody has performed a restore from it, which means the recovery objective is a belief rather than a control — and the day you first test it is the worst possible day to find out how long it takes.
A bill, drawn to scale — then put under load
Six lines, sized by what they cost. Change the load profile and watch which blocks move and which sit exactly where they were: that difference is the whole of cost work. Every block carries its own arithmetic, because a number you cannot reconstruct is a number you cannot argue with.
SIX LINES · ONE ENVIRONMENT PAIR · ILLUSTRATIVE
The everyday shape. Compute leads, egress is larger than anyone expects, and a fifth of the bill is capacity nothing is currently using. Change the profile above and watch the blocks rearrange.
The engagement this instrument describes is one to three weeks and produces workings rather than a headline. You get the line-by-line arithmetic: what each resource is, who or what it belongs to, what it would cost right-sized, and what stops working if it goes. If the bill is already tight, the read says so and it is short.
Five providers on the bench, and what each is honestly good at
We hold no partner status with any of them, and there is nothing on this page that a partner badge would make truer. What we have is the boring, useful thing: enough time on each to know where the bill goes and where the migration hurts. AWS, GCP and DigitalOcean are the three we run most, and we run them on equal terms — the choice belongs to your workload shape, not to our habits.
Because the infrastructure is in code from the first week, the provider decision stays revisitable. That is the actual argument for Terraform — not elegance, but the ability to price the alternative later without a rewrite, and to import the resources somebody created by hand in a hurry rather than leaving them outside the model forever.
The edge either halves your egress or quietly does nothing
A CDN in front of an origin is not a setting you turn on. It is a set of decisions about what is cacheable, for how long, keyed on what, and what happens when it is wrong — and the difference between a considered configuration and a default one shows up on the same invoice line the cost read is about.
DNS and zone management, proxying and TLS, cache rules and the cache keys behind them, page and redirect rules, the WAF and managed rule sets, rate limiting on the endpoints that deserve it, bot controls, Workers for logic that belongs at the edge rather than in the origin, R2 where egress is the thing being avoided, and Turnstile on forms.
Distributions and multiple origins, cache behaviours split by path, cache-policy and origin-request-policy design, origin shield where the origin is the fragile part, signed URLs and signed cookies for private assets, Lambda@Edge and CloudFront Functions for header and routing work, and invalidation used sparingly rather than as a deploy step.
Cloudflare Turnstile runs on the forms of this site. It renders explicitly rather than by class scan, it challenges on submit rather than on page load — so a visitor who never touches a form is never challenged and no token goes stale while they read — and the token is verified server-side before a lead is ever written. Open the contact form and you are looking at it.
An origin that is slow because a query is slow. A cache key that includes a session cookie, so nothing is ever shared. Assets served with no cache lifetime at all. We measure the hit ratio and the egress before and after, because “we put a CDN in front of it” is a sentence, not a result.
Whose accounts, whose keys, whose Terraform state
This is the question the security owner is actually asking, and it deserves a plain answer rather than a paragraph about our commitment to security. We work inside your accounts, never around them.
Only what the work requires, in your cloud accounts, under your access model, with least-privilege roles and credentials you can rotate or revoke without asking us. Named human identities rather than a shared login, so an audit can reconstruct who changed what.
Never in the repository, never in the build log, never in a message. A secret manager your team already controls, OIDC federation instead of long-lived provider keys sitting in CI, and rotation that is a procedure rather than an intention.
Terraform state lives in your account with locking, versioning and a plan a human reads before anything is applied. DNS, domains and certificates stay in your registrar and your zone. There is no point in the engagement at which we hold something you cannot take back the same afternoon.
The runbook is written for whoever inherits it, not for us: how to deploy, how to roll back, how to restore, what each alert means and what to do about it at three in the morning. If we are the only ones who can operate what we built, the job was done badly.
The second year is where infrastructure is judged
Launching a system is a project. Keeping one correct through years of provider changes, dependency upgrades, new payment flows and a market that opens at a fixed time every morning is a different discipline, and it is the one this page is really about. Behind these screens are live market feeds, billing, a CRM and analytics — and a deploy path that had to stop being an event. Earn2Trade case →
Four systems we have run, and what was hard about each
Every one of these has a case page behind it. Longevity is first because it is the strongest infrastructure claim available and the easiest for you to check.
Operated for years
Market hours
A platform we have run, not just built
A trading back office with live market data, a CRM, billing and analytics, serving 8,000+ monthly active users, operated through years of change for a client now in a long-running relationship with us — many of our clients have been with us 7+ years straight. The hard part is not the first release. It is that the thing has to be correct on an ordinary Tuesday during market hours, two years after the people who designed it moved on to other work. Earn2Trade case →
Tests in CI
Core banking
Tests wired into every pipeline execution
Automated end-to-end coverage of a UAE neobank's core banking journeys, running in CI on every change rather than in a manual pass before every release. The hard part is that a flaky suite guarding a payment journey is worse than no suite at all, because people learn to ignore red and then learn to ignore red that means something. Stability of the suite is the deliverable; coverage is the easy half. Neobank QA case →
EDR · SIEM · IPS · IDS
Automated response
A response that does not wait for a human rota
An open-source-based product joining EDR, SIEM, IPS and IDS, with kernel-level detection and remediation that runs automatically. The hard part is acting on a signal that might be wrong: the blast radius of a false positive, the rollback, the audit trail of what the system did on its own. That is the same problem as an autoscaler reacting to the wrong metric or a deployment healing itself into an outage — one layer down, with higher stakes. Cybersecurity case →
Multi-year
Embedded R&D
Where we learned what a rollback is worth
A multi-year firmware programme for a novel power station for PV systems, for sonnenrepublik.de. Firmware has no rollback story unless somebody builds one: there is no console to open, no instance to replace, and the device is in a customer's home. Designing recovery before the first update ships is a habit that transfers directly to a deployment strategy, and it is why we ask about your rollback before we ask about your cluster. Sonnenrepublik case →
Where our experience is provider-specific we say which, and this page names no managed-Kubernetes estate run for a client because we are not claiming one. The Kubernetes competence below is written at exactly the level it exists — and the operating record above is what carries the weight.
Bring one deploy and one invoice to the Data Flow Audit. Those two artefacts answer most of what we would otherwise spend a week discovering.
Kubernetes, including the advice not to
We have done a great deal of this work and we are comfortable anywhere in it. We also think most products we are shown do not need a cluster, and that a page recommending the heaviest option to everyone is transparently selling hours. So here is the competence, written as competence, and then the conditions under which we would actually tell you to use it.
Readiness against liveness probes, and the outage that comes from confusing them — a liveness probe wired to a dependency will restart a healthy pod into a cascade at exactly the wrong moment. Resource requests and limits, and the CPU throttling that arrives at the application team disguised as slow code. Pod disruption budgets, affinity and topology spread, so a node drain is a routine event.
Horizontal autoscaling on a signal that reflects the work — queue depth or concurrency rather than CPU on a service that waits on I/O — plus the cluster autoscaler beneath it, ingress controllers, certificate issuance and rotation, and the difference between a rolling update that drains connections and one that drops them.
Node and control-plane upgrades, which are routine right up until the day they are not; the stuck finalizer that leaves a namespace terminating forever; CRDs and controllers and who owns them after the person who added them leaves; RBAC that is actually restrictive; and secrets that come from somewhere other than a manifest in the repository.
Helm or Kustomize with values that are reviewable, immutable image tags rather than a tag that quietly moved, environment promotion by digest, and a rollback that has been exercised in front of you rather than documented. The manifest is not the deliverable; the ability to change it safely on a Thursday afternoon is.
When we would say yes: several teams deploying independently, workloads with genuinely different scaling shapes, a real need for the ecosystem around it, and someone whose job includes owning it. When we would say no: a handful of services at moderate scale that containers on a managed platform would run for a fraction of the operational cost. That recommendation arrives in writing, with the reasoning, and it costs us hours to give — which is roughly the point.
The read is a conversation, not a report you receive
Half of what makes a cost or deploy read useful is context an invoice cannot hold: which environment belongs to a customer pilot nobody has cancelled, which service is about to be replaced anyway, which alert everyone silently ignores. We ask, you answer, and the workings get written down while the answers are still fresh. You keep the document whether or not anything follows. About Fluvius →
The work, as we actually sell it
Timelines are indicative ranges and depend on scope. Every one of these starts small enough to cancel, and each produces an artefact you keep.
Read the bill, line by line
1–3 WEEKSTagging and per-environment attribution, right-sizing, idle and forgotten environments, storage tiers, egress modelled rather than discovered, and reserved or committed-use cover where the baseline is genuinely stable. You get the workings, so any saving is verifiable rather than claimed. The fastest engagement here to justify.
Merge to production, with nobody in the middle
2–6 WEEKSBuild, test, scan and deploy on merge; environment promotion by immutable artefact; secrets that never reach a build log; OIDC federation instead of long-lived keys in CI; and a rollback that gets exercised while everything is calm.
Terraform in your repository
3–8 WEEKSInfrastructure reviewed like any other change, state held and locked in your account, drift between code and console found deliberately, and the resources somebody created by hand imported rather than left outside the model. You get an environment that can be rebuilt with a command.
Signals you will still read in month three
2–6 WEEKSStructured logs with a correlation id that survives a queue hop, metrics with cardinality you can afford, traces across service boundaries, dashboards for the journeys that matter, and alerts tuned so that a page still means something by the time the novelty has worn off.
A restore performed in front of you
1–3 WEEKSAutomated backups, recovery objectives written down as numbers, and then the part almost nobody does: an actual restore into a clean environment, timed, with you watching. After that the objective is a control instead of a belief.
A written answer on whether you need a cluster
1–2 WEEKSA recommendation with the reasoning, based on your workload shape, team size and deployment independence. If it says yes, it comes with probes, resource limits, autoscaling signals, upgrade cadence and a runbook. If it says no, we build the simpler thing instead.
Provider choice, and how to leave one later
2–4 WEEKSAWS, GCP, DigitalOcean, Hetzner or Azure chosen on workload shape and modelled bill rather than on fashion — with the migration path costed, and the infrastructure in code from the start so revisiting the decision is a plan rather than a rewrite.
The edge, configured deliberately
1–3 WEEKSCache rules and cache keys, WAF and rate limiting where they belong, bot and form protection, Workers or edge functions for logic that should not travel to the origin — measured on hit ratio and egress before and after, so the change is a result rather than a sentence.
What you are probably thinking
The record behind the pages
Many of our clients have been with us for 7+ years straight. The Upwork and Clutch records are independently verifiable. We hold no cloud-provider partner status and no certification badges, and none appears on this site.
Looking for this as an engagement rather than a stack? DevOps & Cloud services — releases that stop being events covers the same discipline sold as a retained team, with the outcomes and the process rather than the tool-level detail on this page. See also Code & Developer Audit and all our work.
Not ready to talk? Take the checklist.
One page: 17 questions about your infrastructure you should be able to answer without opening the console. Who holds Terraform state and where. When the last restore was actually performed, and how long it took. What the rollback procedure is and when it was last exercised. Which environments have no owner. Where long-lived provider keys still live. What your three largest cost lines are, and which of them moves when traffic does.
Bring one deploy and one invoice.
A free 30-minute working session, not a sales call and not a demo — there is nothing to demonstrate. Show us how a change reaches production today, and last month’s bill. We tell you which of the two is costing you more, and what we would change first.
You keep a one-page read either way: the current path to production with its manual steps marked, the three largest cost lines with an estimate and the workings behind it, and a straight answer on whether your workload wants a cluster or emphatically does not. Nobody follows up more than once.
