We read before we touch
Every engagement opens with a review. Changing infrastructure nobody has read is how outages get made, and we would rather spend two weeks looking than two nights recovering.
About
A small AWS team that runs production
We design, migrate and operate AWS for SaaS products and enterprise teams, and we stay on the pager after the project ends.
Founded 2018AWS onlyNamed engineers
150+
customers served
190+
projects delivered
50+
SaaS migrations
7 yrs
longest running engagement
Why we exist
Most teams do not need a cloud department
They need two or three people who have seen this before, reachable when something breaks and honest when a plan is wrong.
Hiring that in-house means a platform team you then have to keep busy. Buying it from a large managed provider means a queue, a ticket number and a first-line agent reading a runbook written by someone who left.
We sit in between. Small enough that the engineer on your account knows your architecture without looking it up, and old enough to have made the expensive mistakes already, on someone else’s budget.
We only work on AWS. Knowing one platform properly beats knowing three of them well enough to be dangerous.
Who runs it
Hardik Shah
Founder and Principal Engineer
Started iNube in 2018 with one other engineer and has run it since. Still does the reviews: the first two weeks of most engagements are his reading, and the ranked list at the end has his name on it.
Questions about an account, a bill or an architecture go straight to him at [email protected]. Answered within 24 hours.
How we work
Six rules we do not bend
One engineer, by name
You get a person, not a shared inbox and a ticket number. They know your architecture because they read all of it, and they answer the phone.
Everything in code
Infrastructure built by hand cannot be rebuilt, by you or by us six months later. New work lands in Terraform and old work moves there as we touch it.
Findings in writing
Verbal recommendations get forgotten and then argued about again. Ours go in a document with cost, effort and risk against each item, so decisions have a record.
We say no
Kubernetes for four containers. A service mesh for one team. A migration in the same quarter as a launch. If the work is a bad idea we say so before it is billable.
Handover is the goal
The best ending is your team taking the pager back because the system stopped needing us. Several clients have. Being recommended beats being retained by inertia.
History
How we got here
- 2018
Two engineers
The first clients were small SaaS teams who needed AWS handled while they built product. One of them is still with us.
- 2020
We took the pager
Clients kept asking who was watching at night. We started running production, and built the monitoring that made that a reasonable promise.
- 2022
Platform work
Single-tenant products hitting their ceiling. Multi-tenancy, metering and per-tenant cost became a large share of what we do.
- Now
150+ companies
Still small, deliberately. Every client gets a named engineer, so we take on as many clients as that can carry and no more.
How big is the team?
Small enough that you will know everyone who touches your account by name. We staff engagements with the people who did the review rather than handing them to a delivery pool afterwards.
Do you work with clients outside India?
Yes. Most of our clients are elsewhere, and we work in their hours rather than expecting them to work in ours. The office is in Ahmedabad, Gujarat, India.
Do you only do AWS?
Only AWS. We do not do Azure or GCP, and when a problem is genuinely better solved on another cloud we say so rather than pretending otherwise.
What happens if we want to take the work in-house?
That is the intended ending. Everything is in Terraform in your repository with runbooks beside it, so your team can pick up the pager without a rebuild. Several clients have done exactly that.
How quickly do you reply?
Within 24 hours, to an engineer rather than a form router. Clients on managed operations reach us outside business hours through the on-call number in their runbook.
What sort of company is a bad fit for you?
Anyone who wants a body-shop headcount, anyone wanting a rubber stamp on a decision already made, and anyone whose real problem is not on AWS. We say so on the first call rather than three invoices in.
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.