Software and web development in the US

The contract, and what happens if this goes wrong

We are happy to contract under the law of your state, and for most US clients that means Delaware, New York or California. Agreeing costs us nothing and every US buyer asks, so it is the easy part of the conversation. The harder part, and the one nobody puts on a first call, is what that clause is actually for, which is the day one of us has let the other down.

So here is the honest version. A US court judgment is not directly enforceable in India, because the United States is not a reciprocating territory under section 44A of the Civil Procedure Code, and a judgment against us would have to be brought again as a fresh suit in an Indian court. An arbitration award travels considerably better, since both countries are parties to the New York Convention, so if the contract is large enough for any of that to matter your counsel will want an arbitration clause with a named seat and institution rather than a courthouse, and we will sign one. We are not going to pretend the border is not there. What carries the weight in practice is commercial rather than legal: payment staged against milestones you have accepted means what you have exposed at any one moment is a milestone rather than a project.

Intellectual property transfers to you on final payment, in writing, and US counsel usually wants that clause to say it two ways rather than one. Work made for hire is a defined term in US copyright law and it does not automatically cover commissioned software, so an agreement resting on those four words alone can leave ownership arguable years later. We are happy for a present assignment to sit behind the work made for hire language as the backstop your lawyer will look for. Repositories move to your GitHub or Azure DevOps organization, hosting and domain accounts are registered to your company from the start rather than to us, and no license comes back to us for anything written for you.

Getting set up as a vendor, and how the money moves

Before a purchase order exists, somebody in accounts payable has to create us as a supplier, and that is where a foreign vendor usually loses two weeks. The portal will offer a W-9 by default, because it was built for domestic suppliers and nearly all of them are. A W-9 is for US persons. A US payer generally requests Form W-8BEN-E from a foreign corporation instead, and we complete and return it during onboarding rather than three weeks later with the first invoice stuck behind it. It does not sit in the file forever either: a W-8BEN-E generally expires at the end of the third full calendar year after it is signed, so it belongs in a diary rather than a folder. What your controller concludes from that form, including whether any withholding or reporting applies and whether the income tax treaty between India and the United States bears on the payment, is a determination for your own tax advisers rather than ours.

There is no sales tax line on our invoices, and no Indian tax is added to them either. Sales tax in the US is a state matter rather than a federal one, and we will not add a percentage we have no standing to collect. Whether your purchase is taxable where you sit, and whether your state expects you to self-assess use tax on services bought from outside the country, turns on the state and on how your finance team categorizes the spend. That is a question we would rather your accountant answered before the first invoice than unpicked at year end. The figure on the invoice is the figure that leaves your account.

We quote in US dollars and hold the figure for the project. If the rupee moves against the dollar in month three, that is our exposure rather than a change order pointed back at you. The usual arrangement is 30% on signing, then 30% on design approval, 30% on development complete and 10% at launch. Net 30 is the US default and we will work to it where the contract says so, but it is better settled in the contract than discovered on the third invoice. Payment comes by wire or through Wise, which most accounts payable teams find less painful than a SWIFT instruction, and we do not ask anyone to put a five-figure invoice on a card, because those fees buy nobody anything. Invoices carry full details for both companies and an itemized description of the work, because a thin invoice is the one that sits in a queue for a month.

The security review, and what we do not have

Almost every US engagement above a certain size meets a vendor security review, and it usually arrives once everyone technical has already agreed on the work. So here is the plain version, ahead of it. We do not hold SOC 2. We do not hold ISO 27001. If either is a hard gate in your procurement process, we are not the right supplier, and we would rather you knew that in week one than in week six.

What we can do is the rest of it. We will complete your security questionnaire, whether that is your own spreadsheet, a SIG Lite or a CAIQ, and answer the rows where the answer is no as directly as the rows where it is yes. We will document how access is granted and revoked, where code and credentials live, what multi-factor authentication is enforced on, and which sub-processors touch anything of yours. We will accept named security obligations in the contract, including a breach notification timeline. A control written into a signed agreement is enforceable against us, which an attestation we do not hold would never have been.

Your procurement pack will also ask for a certificate of insurance, usually general liability and professional liability at stated limits, often cyber, and frequently with your company named as an additional insured. Raise that in the first fortnight rather than at signature, because it is the request that most often arrives in the last week and stops a signature dead. Where your limits need cover we do not already hold, arranging it takes time and costs money, and that belongs in the number and the timeline rather than in a scramble the day before kickoff.

Privacy here is state law, not one national act

There is no federal privacy statute to build against, which is the first thing that surprises a team who has been through a GDPR project. The obligations come from the states, principally the CCPA as amended by the CPRA in California, with Virginia, Colorado, Connecticut and a lengthening list behind it, and they do not all use the same words for the same roles. Whether any of them reaches you turns on thresholds around revenue, how many consumers in that state you hold data on, and whether you sell or share personal information. That determination is your counsel's rather than ours, and we would rather have it before the schema is designed than after.

Where the CCPA does apply, what it means for the build is specific enough to design against. Requests to know, delete and correct have to be things the product does, with a real queue behind them, rather than a manual database job for whoever is free on a Friday afternoon. Selling and sharing have technical definitions that catch analytics and advertising integrations most teams would never describe as a sale, and an opt-out signal such as Global Privacy Control has to be honored rather than quietly dropped. Under the CCPA we are a service provider rather than a processor, and that status exists only where the contract carries the specific terms the statute asks for, so we sign them, and where your counsel has already drafted an addendum we sign yours rather than insisting on ours. If you are covered by HIPAA, GLBA or FERPA, those sectoral rules change the design and not just the paperwork, so name them in the first conversation rather than the fifth.

One difference from Europe is worth stating rather than leaving you to assume. US law puts no general restriction on personal information leaving the country in the way UK and EU law does, so nothing here needs a transfer mechanism in order to exist. What actually binds the build is your own commitments, in your privacy notice and in your customer contracts, and we treat those as the requirement. We process from India under the Digital Personal Data Protection Act 2023, we can tell you what we hold, where it sits, who can reach it and how long it is kept, and we sign a processor agreement that says so. Where the data has to stay in the US, hosting goes in a US region you pick and the data path is documented well enough that your security reviewer can follow it without booking a call with us. There is also no single breach clock here: deadlines are set state by state, and the contract you have already signed with your own customers often sets a shorter one than any statute, so we build the logging to the tightest number you are committed to rather than working it out during an incident.

What a week looks like with no overlap at all

This is the widest gap of any market we work in, and we are not going to dress it up. India runs nine and a half hours ahead of New York on daylight time and ten and a half hours ahead in winter. Our day is nine to six India time, so it ends at half past eight in the morning on the East Coast in summer and half past seven in winter, half past seven or half past six in Chicago depending on the season, and before dawn on the West Coast either way. An early starter in New York catches the last half hour of our day, at seven in winter or eight in summer. Nobody else catches anything. The follow-the-sun line exists to make that sound like a benefit. It is a constraint, and the useful thing is to build the working method around it rather than sell it.

One window does genuinely work, and it is the mirror image of the one you would expect. Our morning is your previous evening. We start at nine in India, which is half past ten or half past eleven at night in New York, and half past seven or half past eight in the evening on the West Coast. A Pacific client can reach us live at eight in the evening their time with our whole day still ahead of us, which is the one respect in which this gap is easier in the west than in the east. The single scheduled call a week sits in our evening for an East Coast client, because nine at night here is late morning in New York, and the cost of that hour is ours rather than yours.

The rest of the method is written first, and here that is a requirement rather than a preference. A handover lands at the end of our day, which is your early morning: what moved, what is next, what we assumed where we could not ask, and anything that will block us tomorrow if it goes unanswered today. It is worth being plain about what the gap costs, because it is not nothing. A question only you can answer costs a day rather than an hour: we ask at eleven in the morning our time, you read it when you get in, you reply during your afternoon, and we act on it the following morning. Pairing on a strange bug over a screen share barely happens, and discovery suffers most, because it is made almost entirely of small questions. We cut that cost by writing decisions down with a default already chosen, so an unanswered question slows the work rather than stopping it. It reduces the cost. It does not remove it, and a team that needs an answer inside the hour through its own working day is better served by a supplier in its own time zone, which we would rather say before a contract than apologize for afterwards.

Questions US clients ask