Services · 05

Cloud & DevOps

It 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
Right for
  • 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
You receive
  • 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
How it runs

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.

Case study

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.

Time returned · Clinical research · Hyderabad
11 daysthen2 days

Query raised to query closed

from a monitor raising a query to the site resolving it

Research organisation · 40 sites · Hyderabad · Clinical research

A vital signs form entered at the site, with checks raised as the values go in: a blood pressure outside its expected range, a date that cannot follow the visit date and a required answer left blank, beside the open query count and an audit trail of who changed what and when. A drawing of the screen described here. Not a screenshot.What else we agreed to measure
  • 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
Read the story
Questions owners ask

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

Read next

A cost model is a deliverable

Why what a system costs to keep running is agreed before it is built, not after.

Start

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)