Cloud infrastructure and DevOps in New York
Many New York firms run a cloud account that grew by hand. A contractor built the first environment, a product team added a second, and a data project added a third. Nobody is sure what is running, who created it or whether it still matters, access is a mix of personal logins and shared keys, and the bill has grown every quarter without anyone deciding it should.
Infrastructure written as code answers most of that by construction. We bring what you have under Terraform, so the list of what runs comes from the same files that build it rather than from a spreadsheet that drifts. Access moves behind your identity provider with multi-factor sign-in, old keys are retired, and the change history shows who changed what and when. Deploys move into CI, and monitoring pages a person only when a person is needed. Along the way we find and remove the resources nobody uses.
Most software bought in New York is bought by companies that do not think of themselves as software companies. Banks, insurers, asset managers, publishers, agencies, fashion houses and property firms all run on systems that sit beside the real business: a client portal, a pricing engine, a reconciliation job, a content pipeline. Those systems rarely start from nothing. They connect to a vendor platform, a core system older than the team, and a folder of spreadsheets someone updates by hand, and the brief is usually to make all three agree.
What those companies need built follows the industry. Asset managers and insurers need client portals where a family office sees two funds and not a third, and overnight jobs that reconcile custodian, market data and order feeds before the market opens. Publishers and ad-tech firms need event pipelines whose delivery numbers agree across vendors, and front ends that stay fast under the ad stack. Property firms need apps for technicians working in basements with no signal. And founders who left one of these industries need a first version in front of a pilot customer before the interest cools.
Hiring is the constraint. Engineers here are courted by banks, big tech offices and funded start-ups at the same time, and Built In puts the average software engineer base salary in the city at about $160,000 before bonus. The shape this produces is a small in-house team that keeps the core systems running, and behind it a list of well-defined projects that nobody on that team will reach this year. That list is where we are useful: each project is a defined piece of work, it starts with a fixed-price two-week piece, and the code belongs to you from the first commit.
We are in Bengaluru and move our working day for New York. Four hours of every working day overlap with your morning in Eastern time, stand-up included, so decisions and code review happen live with the engineer who writes the code. Runbooks and architecture notes are written as we go, so your in-house team can run what we build long after the project is finished.
We are the right fit for the defined projects your in-house team is too stretched to reach this year: a client portal, a reconciliation job, an event pipeline, a first version for a pilot customer. Senior capacity starts within days, the first piece is a fixed-price two-week engagement, and agencies can ship the work 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 New York teams.
How do you work with teams in New York?+
We are in Bengaluru and move our working day for New York, so four hours of every working day overlap with your morning in Eastern time, stand-up included. Calls, reviews and decisions happen in that window, and the rest of the conversation runs in your tools: Slack, GitHub, Linear. The person on every call is the engineer who writes your code, and the code sits in your repositories from the first commit.
Do you build for New York financial firms?+
Yes. The work is usually the systems beside the trading or underwriting desk: overnight jobs that reconcile custodian, market data and order feeds before the open, client portals where investors, brokers and their accountants each see exactly what they should, and internal tools that replace a pricing or renewals workbook only one person understands. We build them to be idempotent and traceable, so every figure can be followed back to the file it came from.
How does your rate compare to hiring in New York?+
Built In puts the average software engineer base salary in New York City at about $160,000, before bonus and benefits. Our published rate is $35/hour, or $5,400 a month for an embedded engineer, with a $5,000 minimum. There is no recruiting time and no employment overhead, and work starts within days of the call. The first piece is a fixed-price two-week engagement at $2,800, so you judge us on working code.
Can you take over a system another vendor built?+
Yes. In New York that is often a client portal or an internal tool built by an agency that has since moved on, with nobody in-house who knows how it runs. We start by reading the code and running it, then write down how it works and where it is fragile before changing anything. A good first two-week piece makes the riskiest part safe and leaves your team runbooks it can use.
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.