Cloud infrastructure and DevOps in Seattle
Most Seattle companies do not need to leave AWS. They need the account they have to make sense: resources created by hand during incidents, environments nobody remembers starting, instances sized for a launch that happened long ago, and tags applied by some teams and ignored by others.
We bring it back into code and into order. Hand-built resources are imported into Terraform, environments are tagged and owned, idle capacity is found and removed, and deploys go through CI with a rollback that has been tested. Alarms point at named owners and runbooks say what to do. We run our own product on self-hosted Kubernetes because it suits us, and we are clear that for a team with a cloud agreement and no appetite for owning a cluster, staying managed is usually cheaper overall.
Seattle's software market was shaped by Amazon and Microsoft, and by the cloud platforms they run. Many of the region's startups were founded by people who left one or the other, and they cluster in cloud infrastructure, developer tools, enterprise software and, increasingly, AI. Around them sit life sciences and global health organisations, retail and outdoor brands, and a long tail of companies whose entire estate lives in AWS or Azure. Buyers here have usually run services at scale themselves, and it shows in what they ask for.
The practical effect is more rigour and less explaining. A Seattle buyer expects a written design before code, with the alternatives considered and the reasons one was chosen. They count metrics, alarms and a runbook as part of done, not a later phase, and they want trade-offs stated plainly. Most already have a cloud agreement and committed spend on AWS or Azure, so the job is usually to make that estate tidier, cheaper and better understood. The other common pattern is the founder who left a large company and misses its internal platforms, because at a startup nobody has built them yet.
Built In puts the average base salary for a software engineer in Seattle at around $149,000, and the large employers add stock on top, which is what a startup is really competing against. A senior search can run for months, and the work that waits is often the most concrete on the roadmap: a service split out of a monolith, a migration, a cloud clean-up, a model moved from a notebook into production. Each has a clear finish line, which makes it a good fit for a small team that writes the design first and the runbook as it goes.
We work from Bengaluru with four hours of live overlap every working day, placed across your morning in Seattle. Stand-ups and design reviews happen in that window, with the engineer who writes the code. Everything decided outside it goes into your repository, your tracker and the architecture notes we write as we go, so each day starts with a written record of what changed.
We fit best on work with a clear finish line: a new service, a migration, a cloud clean-up or a model moved into production. We add senior capacity within days while a req stays open, starting with a fixed-price two-week piece. Agencies can bring us in white-label, under their own name.
Four ways this arrives.
Resources were created in the console over several years and nobody can say which ones matter. We inventory the account, bring what is live into Terraform, remove what is not, and hand you a repository that describes the whole estate.
It is usually idle capacity, oversized instances, forgotten environments and data transfer nobody priced. We find where the money goes, cut the obvious waste where you already are, and only then ask whether a cheaper provider such as Hetzner suits your steady workloads.
One person knows the steps and every release waits for them. We build a pipeline that tests, builds and deploys on merge, with rollback to the previous image, so shipping on a Friday afternoon is a decision rather than a gamble.
The channel fires all day, so everyone has muted it, so real outages are reported by customers. We alert on what users actually feel, route each alert to a named owner, and delete every alert nobody would act on at 3am.
A K3s cluster on Hetzner that we provisioned and are on call for, deployed through Flux, where only a push to master can produce an image production will run.
Read the write-up →Asked by Seattle teams.
How do you work with teams in Seattle?+
From Bengaluru, with four hours of live overlap every working day placed across your Seattle morning. Stand-ups and design reviews happen in that window, and you talk to the engineer who writes the code. We work in your Slack, your GitHub and your Linear. Designs are reviewed before code, and runbooks and architecture notes are written as we go, so the record lives where your team already works.
Do you work with teams already running on AWS or Azure?+
Yes, and in Seattle that is most teams. We work inside the estate you have: hand-built resources imported into Terraform, serverless functions made idempotent and traced end to end, cloud costs broken down per customer and feature, and AI features built on Bedrock or Azure OpenAI through the access your agreement already covers. The aim is an account that is tidier, cheaper and easier to explain, on the cloud you already pay for.
How does your rate compare to hiring in Seattle?+
Built In puts the average base salary for a software engineer in Seattle at about $149,000, before stock, benefits and recruiting fees. Our published rate is $35 an hour, with a $5,000 minimum. There is no recruiting search and no employment overhead, and we can start within days. The usual first step is a fixed-price two-week piece at $2,800, so you judge us on shipped work before committing to more.
What do the first two weeks look like?+
You share the context, and within two days you have a 30-minute call with the engineer who would do the work. Within a week you get a written plan: the options, the one we recommend and why, and how it rolls out. Then comes a fixed-price two-week piece, built in your repository from the first commit, with the design reviewed before code and the runbook written as it goes.
Should we run our own Kubernetes cluster?+
Usually not. Self-hosting starts to pay when your managed bill is mostly things you do not use, your workloads are steady rather than spiky, and someone is willing to own the control plane. We run our own on Hetzner, so we know what that job involves. If nobody on your side wants it, managed is cheaper in total even when the invoice is larger.
Do we need Kubernetes at all?+
Often not. Plenty of products are better served by a managed container service, a platform like Railway, or two virtual machines and a good deploy script. Kubernetes earns its place when you run several services, have steady traffic and have people to look after it. We will recommend the least infrastructure that does the job, and say so when that is less than you expected.
Which clouds do you work with?+
AWS most often, then Google Cloud, Azure and Hetzner. We work in whichever one you are already on, because moving clouds is rarely the cheapest fix for a cost or reliability problem. If we think a move is worth it, we will show you the case using your own bill before anyone migrates anything.
Can you cut our cloud bill without a migration?+
Usually, yes. Most of a bill that has grown unchecked is idle capacity, oversized instances, environments left running and data transfer nobody priced, and all of that is fixed where you already are. We will not promise a percentage before we have read the bill. After the first week we can tell you what is realistic and what it takes to get there.
Who is on call?+
Whoever the engagement says, in writing. While we run your infrastructure it can be us, with hours and response times agreed up front. If you are taking it in-house, the handover includes the runbooks, the alert routing and a rota your team can actually staff. We do not leave behind a pager that only we know how to answer.