Frontend development in New York
New York's publishers and brands run front ends that carry far more than the product. Ad tags, analytics, personalisation and tag-manager scripts arrive from different teams, each added for a good reason, until the article page is slow on a mid-range phone and nobody can say which script is responsible. The same codebase usually holds a checkout, a booking form or a subscription flow that nobody has tried with a keyboard or a screen reader since it was built.
We work inside the React or Next.js codebase you have. We measure what each third-party script costs, move what can wait out of the critical path, and agree a performance budget with the teams that own the tags. Then we fix the components that fail with a keyboard or a screen reader, starting with the flows that take money, subscriptions or bookings, and test them by hand as well as in CI. The pages get faster, and more of your readers can finish what they came to do.
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.
We measure on real devices and real traffic first, not a lab score on a fast laptop. The fix is usually less JavaScript: a smaller bundle, images sized for the screen, and third-party scripts that stop blocking the first render.
A procurement checklist, a customer complaint, or a letter from a lawyer. We fix the causes rather than the line items: real buttons, labelled forms, focus that lands somewhere sensible, and automated checks in CI so it stays fixed.
Global state that everything reads, no types, and three versions of the same modal. We add TypeScript file by file, put tests on the flows that make money, and move shared pieces into one component library as screens are touched.
Usually for search visibility or first-load speed. We move it route by route behind the same URLs, so the old app keeps serving while the new one takes over, and nobody has to sign off a risky weekend cut-over.
A Next.js web app with five operational dashboards and Tableau reports rendered in place, without a second login.
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.
Do we need to move to Next.js?+
Not always. If the app sits behind a login and nobody finds it through search, a well-built React single-page app on Vite is simpler to host and easier to reason about. Next.js earns its keep when first load and search visibility matter, or when you want rendering close to the data. We will tell you which case you are before anyone rewrites a route.
Can you work from our Figma files?+
Yes, and we will ask questions about them. Designs rarely show the loading state, the empty state, the error, or what happens when a name is twice as long as the mock-up assumed. We raise those early and propose something, rather than inventing it quietly in code and leaving your designer to find out in review.
Will you build us a design system?+
We will build the one your product needs, which is usually smaller than people expect: design tokens, the components you actually use, and Storybook to show them. We extract it from the screens you already have rather than designing it in isolation, because a component library nobody migrates to is just a second way of doing things.
How do you handle accessibility?+
We build to WCAG 2.2 AA by default, test with a keyboard and a screen reader, and run automated checks in CI so regressions are caught before they ship. Automated tools find only part of the problem, so we also test the key journeys by hand: sign-up, checkout, and anything a user does every day.
Do you only do the front end, or the API as well?+
Either. A lot of front-end pain is really an API shaped for a different screen, and when that is the case we can fix both sides. If your backend team owns the API, we write down what the front end needs from it and agree the contract with them, rather than working around it in the browser.