Cloud and DevOps services cover the layer beneath your application: where it runs, how new versions reach production, how you find out when something breaks, and what the whole thing costs each month. The work is infrastructure as code, deployment pipelines, monitoring, backups and security configuration.
Most growing companies arrive here with the same three symptoms. Infrastructure was set up by hand in a web console, so nobody can reproduce it and one person is the documentation. Deployments are manual and therefore rare and frightening. And the monthly bill has been climbing for a year without anyone able to say which service is responsible.
All three have the same root cause (infrastructure that exists only as clicks someone made once) and the same fix: write it down as code, automate the path to production, and put a number on every resource.
Our work
Two live platforms, how each one reaches production, and the full write-up behind it.
Montage India
15 TB
footage archive on Montage India's NAS, moving to AWS
Queues, Lambda functions, storage, the database and monitoring defined as code in one AWS CDK app. API deploys roll back to the previous build when the health check fails.
How Montage India's 15 TB archive is moving to AWS →Healthcare marketplace · India
1,100+
automated tests across web, API and mobile
Hosted in the AWS Mumbai region: the web app on Amplify, the API as a Docker image on EC2. CI runs the tests against a real PostgreSQL database with row-level security applied.
How we built a multi-tenant healthcare platform on AWS Mumbai →Still running on your own servers or a NAS? Read how small teams move servers and a NAS to AWS, with transfer times and costs.
Already on AWS and the bill keeps growing? Read how to cut your AWS bill without a rewrite, starting with Savings Plans and storage tiers.
What we do
Usually one of these is urgent and the others are quietly overdue. We scope the urgent one first.
Handover includes a runbook: what to do at 3am, written for whoever is on call rather than for us.
What you get
The measure of this work is whether your team can operate the result without calling us. That is the deliverable.
01
Your AWS or Google Cloud organisation, your domains, your repositories. We work inside them with scoped access and hand the keys back. Nothing critical sits in an account you do not own.
02
Terraform or AWS CDK in your repository, so a new environment is a command rather than a memory. Changes get reviewed before they reach production, like code.
03
Backups that have been restored at least once, and a documented rollback. Until a backup has been restored, you do not know it works.
04
What each alert means, what to check first, who to call and how to roll back, written for the person on call at 3am rather than the engineer who built it.
How we work
We do not touch production before we understand what depends on it. Most of the risk in this work is in the surprises.
01 · Audit
3-5 days
Inventory of infrastructure, spend, access, backups and single points of failure. You get the written findings whether or not you continue with us.
02 · Prioritise
2 days
Ranked by what would hurt most if it failed and what is costing most now. You choose what we do; the list is yours either way.
03 · Codify
2-4 weeks
The current environment reproduced as code and checked against what is running today, before anything is changed.
04 · Automate
1-3 weeks
Deployment automated, alerts configured and tuned, backups tested by restoring one for real.
05 · Hand over
1 week
Walkthrough with your engineers, runbook delivered, access transferred. Ongoing support is optional and separately priced.
Fit check
This work pays for itself in avoided outages and reduced spend, or it does not. We will tell you which case you are in.
A few days of investigation produces a written inventory of risk and spend. You keep the findings and the priority list regardless of whether we do any of the work.
Real questions
The questions we get asked most, answered directly.
Four things in practice: infrastructure as code so your environment is reproducible, CI/CD pipelines so deployments are automatic and reversible, monitoring and alerting so failures are detected by systems rather than customers, and cost work so the monthly bill is attributable. Security configuration and backup testing run through all four. It does not include acting as your permanent operations team; the point of the engagement is that your people can run the result.
It depends entirely on how the account grew. Environments built by hand over a couple of years typically carry meaningful waste: oversized instances chosen defensively, development environments nobody shut down, storage in the wrong class, and data taking an expensive network path. Accounts that were built deliberately have far less to find. The audit gives you a specific number for your account before you commit to any of the work, which is the only way to answer this accurately.
You need the outcomes, not the job title. A five-person team does not need a dedicated DevOps engineer, but it does need deployments that do not depend on one person being free, alerts that fire before customers notice, and a backup someone has restored. Those are a few weeks of setup, not a permanent hire. The mistake small teams make is skipping this until an outage forces the conversation.
Whichever one your team can operate. AWS has the deepest service catalogue and the largest hiring pool in India, which is why most of our work lands there. Google Cloud is competitive and often simpler for data-heavy workloads. The provider matters far less than whether your infrastructure is written down and your deployments are automated. A well-run Google Cloud setup beats a hand-clicked AWS one, and moving between them later is rarely the bottleneck people fear.
Only scoped access, only for the duration, and only in accounts you own. We work inside your cloud organisation and your repositories rather than creating anything under our own name, and access is revoked at handover. You should require this of any vendor: if a supplier holds the only credentials to your infrastructure, you have a business continuity problem regardless of how good their engineering is.
Your team runs it, using the runbook and the training session. Some clients take a small monthly retainer for changes and to be reachable during incidents; others take the handover and never need us again. Both are normal. We do not engineer a dependency. If you cannot operate the infrastructure without us afterwards, the engagement has failed at its main objective.
Ready when you are
Start with the audit: a few days of investigation, then a written inventory of risk and spend and a priority list you keep whether or not we do the work.
