DevOps & Cloud Infrastructure
What a DevOps setup actually costs
This work is priced on how much of your delivery path has to be rebuilt while the product keeps serving users, not on the number of servers involved.
Get a scoped estimateWhy the same brief gets very different quotes
Two teams can send the same one-line brief and get answers months apart. "Set up our cloud infrastructure" covers everything from putting a single app behind a managed platform to rebuilding the delivery path underneath a system that is not allowed to go offline. The word hiding the difference is usually "existing".
The question that changes the answer most is whether anything is already in production. Greenfield is a build, and builds are predictable. Taking over infrastructure assembled by hand over several years is an archaeology project first, and the digging is where the time goes.
Cost drivers
What actually moves the number
Each of these is something you can check against your own setup today. If none of them apply, the project you are pricing is smaller than the quote you were handed.
Undocumented existing infrastructure
Infrastructure built by hand leaves no record of why a firewall rule exists. Reproducing it in Terraform means testing each guess against production.
How many environments you keep
Every environment is another thing to build, patch and pay for. A staging environment that has drifted from production is worse than none.
Databases and other stateful services
Code moves easily; data does not. A Postgres cutover needs replication, a rehearsed switch and a rollback path someone has actually run.
How much downtime you can accept
A migration you can run inside a quiet Sunday window is a different job to one that must not drop a single request.
Compliance evidence
SOC 2 wants access reviews, audit logs and change approvals recorded rather than asserted. That recording is build work, and it lands in every pipeline.
Kubernetes, or deliberately not
Kubernetes earns its cost at real scale. Below that it adds a platform your own team then has to operate and upgrade.
Depth of observability
Dashboards and uptime checks are quick. Tracing that answers why one request was slow needs instrumentation inside the application code itself.
Secrets and access management
Moving credentials out of environment files into a managed vault, with rotation and per-service scoping, touches every service and every deploy.
Whether you want an on-call rota
A rota needs runbooks, alert thresholds worth waking someone for, and enough people. Two engineers cannot cover a year between them.
Scope tiers
Four tiers, smallest to largest
The useful line in each tier is the last one, which says what is excluded. That is where a quote and an expectation usually part company.
- TIER 1 — FOUNDATION
- Deployable and backed up, one environment. Ships in 2–4 weeks.
- ₹1L – ₹2L$1.1k – $2.3k
- Containerised app on a managed platform, a pipeline that runs tests and deploys on merge, TLS, automated backups and uptime alerting. Suits a small team shipping a first product. Does NOT include staging, infrastructure-as-code or on-call.
- TIER 2 — PRODUCTION SET
- Staging and production, defined in code. Ships in 5–8 weeks.
- ₹4L – ₹6L$4.5k – $6.8k
- Everything in Terraform, a staging environment matching production, rolling or blue-green deploys with rollback, metrics and alerting, plus a restore drill you watch succeed. Suits a product with paying users. Does NOT include compliance evidence or multi-region.
- TIER 3 — MIGRATION
- A live system moved without an outage. Ships in 3–5 months.
- ₹14L – ₹24L$16k – $27k
- Discovery of what is genuinely running, a rebuilt delivery path, database cutover with replication and rehearsal, traffic shift, then decommissioning the old estate. Suits teams leaving an inherited or hand-built setup. Does NOT include rewriting the application.
- TIER 4 — REGULATED PLATFORM
- Multi-region, evidenced, with tested recovery. Ships in 5–9 months.
- From ₹35LFrom $40k
- Adds audit logging, role-based access, recorded change approvals, encrypted data paths, a second region and a disaster-recovery test against agreed recovery targets. Suits healthcare, fintech and enterprise procurement. Does NOT include the external audit or legal counsel.
Indicative ranges for scoping conversations, not quotes. They reflect what work of this shape has cost us to deliver — your figure comes out of a paid discovery, against a written scope, and is fixed before any code is written. Gas, licences, cloud and third-party audit fees sit outside these numbers.
How we work
How a DevOps project gets scoped
Timelines below are typical for a team with one production system. Scope shrinking after the review is a good outcome here, not a failed sale.
Infrastructure review
1 weekWe read what is running now: deploy steps, credentials, backups, and whether a restore has ever been tested. Most of the surprises surface here.
One service through the new path
1–2 weeksA single service taken end to end on the proposed setup. This is the step that shrinks scope, and sometimes shows you need far less than you asked for.
Build and cut over
4–10 weeksEnvironments in code, pipelines, monitoring, then the database move rehearsed on a copy before the real switch. The cutover is scheduled, never improvised.
Run, tune and hand over
OngoingRunbooks written with your team, alerts tuned against real noise, and a review of what the bill is made of once traffic is honest.
Is this worth budgeting for now?
Worth reading before you get in touch — it saves both of us a call.
Worth budgeting for now if…
- Deploys are manual and one person knows the steps
- A customer contract now asks for access controls and audit logs
- You have never tested restoring the database from a backup
- Outages take hours to diagnose because nothing is traced
Wait, if…
- You are pre-launch and a managed platform still deploys fine
- Nobody on your side will own the setup after handover
- The real problem is application performance, not the infrastructure
- The product is still changing weekly and may be rebuilt
Frequently Asked
Questions
Common questions about scoping cloud infrastructure, migrations, and what it takes to run afterwards.
Four things do most of it. An existing production system that cannot go offline, because every change has to be rehearsed before it is real. Compliance requirements, which turn access control and change approval into recorded processes rather than habits. Stateful services, since a database cutover carries risk a stateless app does not. And the number of environments you insist on keeping. Scale matters less than people expect. A quiet system with strict uptime rules costs more to move than a busy one that tolerates a maintenance window.
Kubernetes, usually. Most products run comfortably on a managed container platform, and adopting an orchestrator adds a system your team must operate for years afterwards. Multi-region can wait until a customer asks for it in writing. Distributed tracing can start life as structured logs. What we would not cut: backups with a restore you have watched succeed, infrastructure defined in code, and a staging environment that genuinely matches production. Those three are cheap to do now and painful to retrofit.
The handover. Infrastructure is only finished when someone on your side can change it without calling us, and that means runbooks, a walkthrough and time for questions. Alert tuning is the second one. Monitoring always ships noisy, and it takes a few weeks of real traffic before thresholds mean anything. Third is decommissioning the old setup, which teams leave running just in case and then keep paying for. Data-transfer charges between regions are the other quiet surprise.
Three buckets, and only one of them is the cloud bill. Compute and storage scale with traffic and are the easiest to bring down once you can see where the spend goes. Tooling sits beside it: monitoring, log retention and CI minutes, all priced on volume, which is why retention windows are worth setting deliberately rather than by default. The third bucket is human time — patching, reviewing alerts, answering pages. That one is usually the largest and the most often left out.
Phase it, almost always. Start with the environment you actually deploy to, get it defined in code and backed up properly, then leave it alone for a while. The second phase adds staging, safe deploys and monitoring, once an outage would genuinely affect users. Compliance work and multi-region belong later still, driven by a signed contract rather than a preference. Phasing also gives you a fair look at whether the next stage is worth buying, which one large build never does.
Have a project in mind?
Fixed price after a paid discovery — no hourly billing. A real engineer reads every enquiry, and we reply within 24 hours.