Deployment should be boring
If releasing is stressful, teams release less often, and less frequent releases are larger and riskier, which makes them more stressful. We break that loop by making a deploy a non-event: merging to the main branch runs the tests, builds, deploys and can roll back on its own. The measure we care about is not how modern the pipeline looks but whether an ordinary developer can ship on a Friday afternoon without asking permission. DevOps on a budget for small teams covers what is genuinely worth automating first when there is no platform team. The application code itself is software development; this page is about everything underneath it.
- Cloud architecture on AWS, Google Cloud or Azure, sized to real load.
- Infrastructure as code, so environments are reproducible.
- CI/CD pipelines with automated tests and safe rollback.
- Containerisation and orchestration where it genuinely helps.
- Monitoring, log aggregation and alerts tuned to reduce noise.
- Backup and restore procedures that have actually been tested.
Cost control as an engineering discipline
Cloud bills grow through neglect rather than through decisions: instances sized for a launch that never came, staging environments running at midnight, snapshots nobody owns, egress nobody measured, and a managed service bought to save a fortnight two years ago. We audit spend against actual usage, right-size, delete what nothing depends on, and put an alert on the bill itself so the next surprise is caught in days rather than at the end of a quarter. Savings are reported as measured before-and-after figures on your own invoice, not as a percentage claim.
Alerts a person will still trust in six months
An alert that fires often and means nothing trains a whole team to ignore alerts, and the outage that follows is the one nobody looked at. We instrument for the handful of symptoms that genuinely indicate user-visible failure, route them to somebody who can act, write down what to do when each one fires, and delete the rest. An alert with no runbook is a notification, and a notification at three in the morning is worse than nothing.
Hosting decisions with Nepal in the picture
Where the servers sit matters more here than the diagrams suggest. Latency from Kathmandu to Singapore or Mumbai is materially better than to Frankfurt or Virginia, and for an audience that is mostly domestic that shows up in every page load. International bandwidth, upstream outages and load-shedding at the office all argue for the application living in a managed region rather than on a box in a rack somebody has to drive to. Where regulation or a client contract requires data to stay in country, we will say plainly what that costs in resilience, because a single local server with no tested restore is not a compliance win. For a marketing site on managed hosting, none of this needs a separate engagement and it is already handled as part of web development.
Surviving the week when things go wrong
Backups nobody has restored are a belief, not a plan. We rehearse restores, document the sequence, and time it, so the recovery estimate is a measured number rather than a hope. That matters in a country with a monsoon: the IT side of getting a business running again after a flood is a real scenario for clients in Chitwan, Birgunj and along the highway, and the difference between a two-hour recovery and a two-week one is decided long before the water arrives. The routine half of the same discipline, the patching and the checks nobody notices until they stop, is set out in what website maintenance actually needs every month.
What goes wrong in cloud & devops, and how we avoid it
- Kubernetes adopted before there is anything to orchestrate.
- We will tell you when a managed platform or a couple of containers is the right answer. Kubernetes buys operational complexity immediately and pays it back only at a scale most products never reach.
- Infrastructure that exists only in the console.
- Anything created by clicking cannot be reproduced, reviewed or rebuilt after a mistake. We bring existing infrastructure into code incrementally rather than rebuilding it all at once, and stop new resources being created by hand.
- Secrets in the repository.
- Credentials go into a managed secret store with rotation, and we audit what has already leaked into git history, because a key committed in 2023 is still a key.
- A staging environment that resembles production only in name.
- Same infrastructure definitions, different sizing and data. If staging is materially different, every deploy is a first attempt and the pipeline gives false confidence.
How we run cloud & devops work
- 01
Audit
We document what actually runs, what it costs, who can access it and what would happen if it stopped. On inherited systems this is usually the first time any of that has been written down.
- 02
Plan
A target architecture sized to real traffic, with the sequence to reach it and the cost at each step. We name what we are deliberately not doing, because most over-engineering is agreed by nobody in particular.
- 03
Automate
Infrastructure into code, pipeline with tests and rollback, environments made reproducible. Existing resources are adopted incrementally rather than torn down and rebuilt.
- 04
Observe
Dashboards, log aggregation and a small number of alerts that mean something, each with a runbook. Then we deliberately break something in staging to see whether the alert fires and whether the runbook works.
- 05
Hand over
Your developers deploy, restore and read the dashboards with us watching, not the other way round. Ongoing support is optional and priced separately.
What cloud & devops costs
Two shapes. A one-off piece of work, an infrastructure audit, a pipeline build, a cost review or a migration, is a fixed price against a written scope, and a cost review frequently pays for itself out of the first month's savings. Continuing responsibility for your platform is the Dedicated Team tier: a DevOps engineer working to your roadmap and your on-call expectations rather than an open-ended hourly arrangement.
Dedicated Team
Your engineering bench, offshore.
- Nepal, from
- Rs 145,000per engineer, per month
- About $1,040 at Rs 140 to the dollar
- International, from
- $2,200per engineer, per month
- A$3,400 · €2,050
Monthly, 3-month minimum
Teams in Australia, the US, the UK, the EU or Nepal outsourcing a squad of developers, ML engineers or DevOps people who work to your roadmap.
What pushes the price up
- Bringing undocumented existing infrastructure under code before anything can be changed safely.
- Compliance requirements: data residency, audit logging, access review.
- Zero-downtime migration of a running production system with real users.
- Multiple environments and multiple accounts that all have to stay in step.
- On-call coverage outside our working hours.
What brings it down
- Starting with the pipeline and the alerts, which is where most of the benefit is.
- A single cloud provider rather than an architecture that avoids committing to one.
- Accepting managed services instead of self-hosting the equivalent.
- Your developers taking over day-to-day operation after handover.
- Every figure here is a starting point, not a quote. You get a fixed price against a written scope before anything is built.
- Nepali clients are quoted in NPR at local rates, with a VAT invoice against our PAN. International clients are quoted in USD, AUD, EUR or GBP.
- You own the code, the domain and the hosting from day one, on every tier.
Who this is for, and who it is not
Worth a conversation if
- Teams shipping regularly whose deploys still involve a person following steps from memory.
- Companies whose cloud bill has grown faster than their usage.
- Products that have outgrown a single server and have no reproducible way to build a second one.
- Organisations that need a tested recovery plan rather than a folder of backups.
Probably not us if
- A small site on managed hosting that is working fine. Adding a pipeline to it is engineering for its own sake.
- Anyone wanting Kubernetes because it was on a job advert. We will ask what it is for and take no for an answer in either direction.
- Teams unwilling to change how they release. Tooling cannot fix a process nobody follows.
Frequently asked questions
Can you take over infrastructure someone else set up?
Yes, and it is most of what we do. We audit first, document what exists, then bring it under infrastructure as code incrementally. Rebuilding everything at once on a system with live users is the riskiest possible way to start and we will argue against it.
Do we need Kubernetes?
Usually not. Most products of the size we see run better on simpler managed platforms, and adopting Kubernetes early buys operational complexity long before it buys anything else. When you genuinely need it, the reasons are specific and we can name them.
Can you reduce our cloud bill?
That is one of the more common reasons clients come to us. We audit spend against actual usage, right-size, remove what nothing depends on, and put an alert on the bill. Savings are shown as measured figures on your own invoice rather than as a percentage claim.
Should we host in Singapore, Mumbai or somewhere else?
For a mostly Nepali audience, Singapore or Mumbai gives noticeably better latency than Europe or the United States, and the difference is visible in page load times. For a mostly international audience, host near those users. If a contract or regulation requires data to stay in Nepal, we will tell you what that costs you in resilience.
How do you handle on-call, given the time difference?
We agree explicitly what is covered and by whom. Our working week is Sunday to Friday, so an American or European team gets overlap on different days from what they might expect. Anything requiring cover outside those hours is scoped and priced rather than assumed.
Do you test the backups?
We restore them, time the restore, and write down the sequence. An untested backup is an assumption, and the moment you discover it was wrong is the worst possible moment to discover anything.
Will this stop our deploys breaking things?
It stops a broken deploy staying broken. Tests run before release, the rollback is automatic and rehearsed, and staging uses the same definitions as production. What no pipeline can do is compensate for changes nobody reviewed.
