FAQ
Questions we get asked before the first engagement.
If something here is unclear, or your question is not covered, ask us directly — we will give you the same answer in email that we would give on a call.
Working together
- Are you a staff augmentation company?
- We can provide engineering capacity when that is genuinely what is needed, but it is not our preferred model. We would rather own a defined cloud or platform scope, or deliver a scoped project, than rent hours. Owning a scope means we are accountable for an outcome; renting hours means you are accountable for directing us, which is usually the thing you were trying to avoid.
- Do you replace our internal DevOps team?
- No. DeClouder either complements an internal team — taking a defined part of the platform so your engineers can focus elsewhere — or provides the platform capability for companies that do not yet need a full internal organization. Where an internal team exists, we agree the boundary between us explicitly.
- Can you work with our existing development team?
- Yes, and this is one of the most common ways we engage. Your developers stay on the product; we take the infrastructure and platform work, review changes that touch it, and keep the paths they use to ship working.
- Can you be our platform team rather than sitting next to one?
- That is a common arrangement. We own a defined platform scope — the cloud environment, the clusters, the pipelines, the Infrastructure as Code — and your engineers own the application and its path to production. When you eventually hire a platform engineer, they inherit documented infrastructure in code rather than a decade of undocumented decisions.
- How do engagements get scoped?
- A conversation, then an assessment of the actual environment, then a written scope covering what we own, what stays with your team, and how support and coverage work. Major projects or work outside an agreed managed scope are scoped separately rather than absorbed.
- Do you publish pricing?
- No. Scope varies enough between environments that a public price would be misleading. Pricing is proposed after we understand what you are running and what you need us to own.
AI implementation
- Can you work alongside our existing engineering or AI team?
- Yes, and it is a common arrangement. We take an agreed piece of work and coordinate with your engineers on interfaces, review and deployment. Where you already have AI engineers, we are usually there for specialist depth on a specific area or for additional delivery capacity on a defined scope.
- Can you help if we are still identifying an AI use case?
- Yes. An assessment that ends in "build this one, for these reasons, and not those" is a legitimate and useful outcome. We would rather tell you a use case is not worth building than build it.
- Can you improve an AI workflow we already run?
- Yes. That normally starts with measurement: a baseline for output quality, cost and latency on the workflow in scope, then improvements prioritized by what the baseline shows — model selection, context handling, caching, retrieval quality or the surrounding integration.
- How do you approach data access and human review?
- Access is scoped to the sources we agree a system should read, granted through your own access controls, and retrieval respects the permissions the user already has. Where output reaches a customer or drives a consequential action, the default is that a person reviews it first. Both are agreed as part of scoping rather than assumed.
- How does an AI engagement start?
- Usually with a focused assessment of an agreed scope, ending in findings and prioritized recommendations. From there it becomes a prototype against agreed success criteria, a defined implementation project, or ongoing engineering support. One reasonable first step is a two-week assessment of a single workflow, subject to scope and the access available.
- Is this the same as the AI you use internally?
- No. AI-assisted engineering is how we deliver cloud and platform work — our engineers use AI tooling as part of the job. AI implementation and engineering is a service, where the AI system is what you are buying. Same standards, different deliverable.
AI in our own delivery
- Do you use AI to operate production systems?
- AI assists our engineering workflows — investigation, drafting infrastructure code, review, documentation, automating routine work. AI-assisted changes travel the same path as any other change: automated validation, a pull request, policy and security checks in the pipeline, engineering approval, then GitOps reconciliation. Production workflows are designed around appropriate validation, approval gates and least-privilege access, and an engineer stays accountable for what reaches your production environment.
- Where does AI actually help?
- Mostly in work that is mechanical or investigative: reading across logs, metrics, manifests and configuration to narrow a problem; drafting and reviewing Terraform and Kubernetes manifests; analysing pipeline failures; generating tests, runbooks and documentation; and applying repetitive changes consistently across many repositories. We use AI coding agents and agentic workflows for this, integrated through MCP and agent SDKs with least-privilege access to engineering systems.
- Why does that matter to us?
- It is why a small senior team can carry the scope it does. You get experienced engineers rather than a larger team of mixed seniority, and the repetitive parts of the work do not consume the hours you are paying for judgment.
Support and operations
- Do you offer 24/7 support?
- Support and coverage are defined as part of each engagement, based on the customer requirements and what the environment genuinely needs. We would rather agree realistic coverage we can honour than advertise a blanket promise.
- Is there a limit to what a managed engagement covers?
- Every managed engagement has an agreed scope. Routine operational work, changes and improvements within it are covered, and larger projects are scoped separately so both sides know what is included.
- How do you handle access to our environment?
- Access is scoped to what the engagement requires, granted through your own identity and access controls, and reviewed as part of the engagement. Least privilege applies to us as much as to anything else we would recommend.
- What happens if we want to take the work back in-house?
- That is a normal outcome, and it is one reason we keep infrastructure in code and documentation current. Handover means transferring code, documentation and context — not extracting you from a dependency.
Technology and scope
- Which clouds do you work across?
- AWS, Azure and GCP, including their managed Kubernetes services — EKS, AKS and GKE — and hybrid estates where some infrastructure is still yours to run. Plenty of the environments we work in span more than one. Tell us what you are running and we will be specific about how we would approach it.
- What technologies do you support?
- The core ground is Kubernetes and managed Kubernetes, Terraform and Infrastructure as Code, CI/CD systems including GitHub Actions, GitLab CI, Jenkins and Azure DevOps Pipelines, GitOps with Argo CD or Flux, observability built around OpenTelemetry, Prometheus, Grafana and the cloud-native monitoring stacks, cloud networking, and the security tooling that belongs in a pipeline. The Capabilities page lists this by domain in detail.
- Do you do platform engineering, or just operations?
- Both, and platform engineering is a large part of our identity. That means the platform your developers build on: Kubernetes, golden paths, self-service environments, reusable infrastructure templates, standardized CI/CD and guardrails — so application developers can consume infrastructure safely without every developer becoming a cloud expert.
- Do you work with GitOps?
- Yes, and we will usually recommend it. Git as the source of truth, changes proposed by pull request, declarative configuration, automated reconciliation with Argo CD or Flux, an auditable history of what changed in production, controlled promotion between environments, and drift removed rather than managed.
- Do you take on-call or incident response?
- We can, and reliability work is a distinct service area — SLI and SLO design, incident response and management, root-cause analysis, capacity planning, DR and failover testing, on-call design and runbooks. What coverage looks like is agreed per engagement rather than advertised as a blanket number.
- Can you help with SOC 2, PCI DSS, HIPAA, CIS or NIST?
- We help engineering teams implement and operate controls aligned with those frameworks: infrastructure controls, hardening, access management, logging and the evidence an audit expects. Formal audit and certification stay with your auditor.
- Do you manage our databases?
- We support databases as part of the broader platform and infrastructure environment — provisioning, high availability, version upgrades, backup and restore testing, replication and failover, monitoring and integration — across PostgreSQL, Aurora and RDS, SQL Server, Cosmos DB, Redis, OpenSearch, Kafka and similar. Schema and query design stay with your engineers.
Still have a question?
Ask it directly and an engineer will answer.