Services · 05
Cloud & DevOpsIt stays up, and you find out before your customers do
Your systems in your own cloud account, put live the same way every time, and watched closely enough that a failure reaches a person rather than a customer.
Boring is the goal.
The systems a business depends on usually grow without anyone deciding where they should live. One runs on a machine under a desk, one on a server a former employee set up, one on a hosting account paid for by somebody’s personal card. Nobody is certain what would happen if the machine died on a Sunday, whether the backup has ever been restored, or why the bill went up last month.
This work makes that part boring. Everything runs in accounts held in your company’s name, the setup is written down as files rather than as steps somebody remembers, putting a change live is something anyone on your team can do and undo the same way every time, and the systems are watched closely enough that a failure reaches a named person before it reaches a customer. We size it to the business you actually are, not to the diagram a larger firm would enjoy drawing.
- Team
- The named owners, for the whole engagement
- Runs in
- Your own accounts, from day one
- Pricing
- Fixed price, billed by milestone; a fixed itemised quote follows the first call
- A system nobody dares to put live on a Friday
- One laptop, or one vendor, that everything depends on
- A cloud bill nobody can explain line by line
- Every account, domain and key in your own name from day one
- A release anyone on your team can run, and undo, the same way
- An alert that reaches a named person, with what to do written down
- A monthly cost you saw in writing before the build
Four gates. You accept each one before the next starts.
The same four as every engagement, as they look for this work.
Diagnose
We write down what you run, where each piece lives, who has the keys, and what happens if any single one of them stops. The findings document ranks those risks by what an outage would cost you, and it names the ones that can be closed in a day.
Prove
One system is moved or rebuilt the new way, with the whole setup written down as files, and the backup is restored for real rather than assumed. What it costs to run is checked against the actual bill, and both numbers are written down.
Build
The rest, fortnightly, in your own accounts. Releases become routine and reversible, alerts start reaching a person with what to do beside them, and the monthly cost is reviewed against what we said it would be.
Hand over
Your team runs it while we are still on call: how to release, how to roll back, who the alert goes to at midnight and what they should do. The review says what is now safe, what is still a single point of failure, and what it would take to close.
Forty sites entering patient data once, with every change logged.
A research organisation running trials at forty hospital sites. Data arrived on paper and by email, and checking a record meant chasing three people.
Query raised to query closed
from a monitor raising a query to the site resolving it

- Data queries raised per 100 fields enteredfields a monitor sent back to a site for correction
- Records with a gap in the audit traila change with no recorded author, reason or prior value
What owners ask before they call.
Where should our systems actually run?
In accounts held in your company’s name, with your finance team paying the bill directly, on whichever provider your team can live with. Beyond that the honest answer is usually smaller than people expect: managed services that someone else patches, rather than machines you have to look after. The decision turns on where your customers are, what must stay inside India for compliance, and what your team can support at three in the morning. We will tell you when the answer is a modest server rather than a platform.
Our cloud bill keeps rising and nobody can explain it. Is that normal?
It is common, and it is fixable. Bills rise when nothing is labelled, when test systems are left running, when storage is never cleared, and when something was sized for a launch that never came. The first step is making every line traceable to a system and an owner, which usually removes a visible share of the bill in the first pass. After that the cost is reviewed monthly against what we said it would be, and a jump raises an alert rather than a surprise at the end of the year.
What happens if a system goes down at midnight?
An alert reaches a named person, on a phone, with the thing that broke and what to do about it written beside it. That is the difference between a system that is watched and one that is merely hoped for. Which failures are worth waking someone for is agreed with you, because an alert that fires for everything is an alert nobody reads. During an engagement a founder is on that list; at handover your team is, with the written what-to-do in your own repository, and a monthly care plan is available if you would rather we stayed on it.
How do we know the backups actually work?
Because one is restored in front of you, on a timetable, and the time it took is written down. A backup nobody has ever restored is a belief, not a protection: the usual discoveries are that one database was never included, that the restore takes far longer than anyone assumed, or that nobody has the credential needed to start it. We agree two plain numbers with you, how much data you could afford to lose and how long you could afford to be down, then test against them rather than against a promise.
Can you take over a system somebody else built?
Usually yes, and the first piece of work is finding out what is actually there: which accounts exist, who holds the keys, what is running that nobody remembers starting. You get that inventory as a document whether or not you continue with us. Where the previous builder left things undocumented we write them down as we go, and where something is genuinely beyond saving we say so plainly, with what replacing it would involve, rather than charging to keep it upright indefinitely.
Do we need our own servers, or is renting enough?
For nearly every business this size, renting is enough and owning is a distraction: your own machines mean someone in your building is responsible for power, cooling, spare parts and the patching nobody enjoys. Buying earns its place in narrow cases, such as a steady heavy load where the rental price never falls, or a rule that says data must sit on hardware you control. We work that out with real numbers at your volumes before anyone signs anything, and the comparison is written down.
For your technical adviser
Infrastructure as code, reproducible environments, CI/CD, observability and backup restores that are actually tested. Right-sized for the business: managed services before clusters, and no Kubernetes unless the load argues for it.
- Infrastructure as code in your repository, no console-only resources
- CI/CD pipelines with rollback, owned by your team
- Dashboards, alert routing and on-call runbooks
- Restore drill results and a documented recovery objective
Stack Terraform · Docker · GitHub Actions · AWS · Azure · GCP · Grafana · OpenTelemetry
A cost model is a deliverable
Why what a system costs to keep running is agreed before it is built, not after.
Write a paragraph. A founder replies within one working day.
A 30-minute call with both founders follows. No deck and no proposal template, just a first read of whether we are the right shape for the problem.
Or by phone or WhatsApp: +91 94330 54299 · WhatsApp (opens in new tab)