AI integration in New York
New York's law firms, research desks and publishers hold the same raw material for a language model feature: a large archive of documents that people search badly. They share the same constraint too. Much of it is confidential, some of it belongs to clients, and the partners, editors or analysts who would use the feature will abandon it the day it gives one confident wrong answer.
So the first piece of work is a map, not a prompt: what leaves your systems, which provider receives it, what that provider keeps, and what stays in your own cloud. Where the answer rules out a hosted model, an open-weight model on your own hardware is a real option, and we price both. Then we build retrieval over the archive with every answer linked to its source, an evaluation set written with the people who will use it, and a fallback for when the provider is down. The feature ships when it beats the search box your team already has, measured on their questions.
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.
A prompt that behaved on twenty hand-picked inputs meets ten thousand real ones. We build the evaluation set from your actual traffic first, so a change can be judged rather than argued about.
Usually a large context sent on every call, or a big model doing a job a small one can do. We measure where the tokens go before recommending anything.
Logging that captures the prompt, the retrieved context, the model version and the output, so a support question has an answer that is not a guess.
A fallback path, a timeout that is shorter than your user’s patience, and a degraded mode that is honest about being degraded.
A weekly maintenance pulse where Claude writes only the prose, checked against a JSON schema and a whitelist of numbers, with a template that takes over when the model fails.
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.
Will you tell us if we do not need a model?+
Yes, and it happens often. Several requests we have taken turned out to be a search problem, a rules engine, or a form with better defaults. We would rather say that in week one than bill for a year of prompt tuning.
Whose API keys?+
Yours, in your accounts, with the spend visible to you. We never proxy your traffic through infrastructure we control.
What about our data going to a provider?+
We map exactly what leaves your systems and where it lands before anything is wired up. Where that is not acceptable, self-hosted open-weight models on your own hardware are a real option and we will price both.
Do you fine-tune?+
Rarely, and not as a first move. Retrieval and prompt structure fix most of what people bring to us as a fine-tuning problem, at a fraction of the cost and with none of the retraining treadmill.