We Signed 9 Node.js Outsourcing Contracts in Dubai — the 5 Delivery Terms I Now Refuse to Sign Without

Nine Node.js outsourcing engagements later, I have stopped negotiating price first. Every serious disagreement we have had came from something the contract simply did not address — and all of them were foreseeable. Here is the sequence, in the order it should be agreed.

Outsourcing disputes almost never begin with money. They begin with two parties holding different, entirely reasonable interpretations of the same sentence, discovered at the worst possible moment. The remedy is not a longer contract. It is a small number of specific, unambiguous provisions agreed before anyone is invested.

What follows is what we now agree before signing, across nine Node.js engagements for UAE-based companies. Steps 1 and 6 do most of the work.

Step 1 — Write the definition of done before the price

“Delivered” is the single most expensive undefined word in software contracting. To one party it means the code runs on a demo environment. To the other it means it is in production, monitored, documented and handed over.

The test to apply is simple: could a third party who was not in any of your meetings decide whether this item is done? If not, it is not a definition, it is an aspiration.

A workable definition names the environment on which the work runs, the automated tests that must pass, the review that must be recorded, the documentation that must exist, and who signs off. For Node.js work specifically, add two items that are routinely forgotten and routinely disputed: dependency versions pinned and the lockfile committed, and a documented list of required environment variables. We have twice received “completed” services that could not be started by anyone outside the vendor’s own machines.

Write this before you discuss the rate. Once a price is on the table, every clarification you request reads as an attempt to get more for the same money, and the conversation degrades.

Step 2 — Decide who owns the environments and the pipeline

This is the provision most often left out and the one with the largest consequences. If the vendor owns the cloud accounts, the repository organisation, the CI configuration and the deployment credentials, then your ability to leave is theoretical no matter what the exit clause says.

Our position, without exception now: the client owns the cloud account, the repository organisation and the domain; the vendor is granted access. This is not a matter of trust. It is a matter of what happens if the vendor is acquired, changes strategy, or simply becomes unresponsive for three weeks.

The provision costs nothing to agree at the start and is nearly impossible to retrofit. On two of our nine engagements we accepted vendor-owned infrastructure to save setup time. Both migrations later cost more than the time they saved — one of them considerably more, because the environment variables existed only in a CI configuration nobody had exported.

Step 3 — Set response times that reference a clock you both see

A commitment to respond within four hours is meaningless if the vendor decides when the clock starts and what qualifies as urgent. Three elements make the clause real.

First, the clock: the request is timestamped in a shared tool, not in an email thread or a chat message that may have been missed. Second, the severity definition, written in terms of user-visible impact rather than technical cause — “users cannot complete checkout” rather than “the service returns 500”. Third, the coverage window: which hours, in which time zone, on which days.

That last point deserves attention for UAE-based buyers specifically, because the working week and the time zone offsets differ from the vendor’s in most engagements. State the overlap explicitly. We commit to a minimum of four overlapping working hours per day and put it in writing; teams that cannot offer that are viable for project work but not for anything with an operational component.

Step 4 — Agree how change is handled, not whether it happens

Every fixed-scope contract changes. Pretending otherwise produces one of two failure modes: a vendor who absorbs changes silently and then delivers late without explanation, or a vendor who raises a change request for every clarification and poisons the relationship in month two.

What works is a threshold. Below an agreed size — we use half a developer-day — changes are absorbed and simply logged. Above it, a short written note stating the impact on scope, date or cost, approved before work begins. No formal procedure, no committee: a paragraph and an acknowledgement.

Then add the provision that makes it work in practice: the log is reviewed together every month. Absorbed changes are visible even though they carry no charge. This is what stops the slow accumulation that ends with a vendor who feels exploited and a client who cannot understand why the date moved.

Step 5 — Name the people and cap the substitution rate

A contract with a company gives you capacity. A contract naming individuals gives you continuity. On knowledge-intensive Node.js work — where most of the value sits in understanding an existing codebase rather than in writing new code — the difference is decisive.

Three provisions, all easy to agree at the start. Name the individuals in the schedule. Require written notice with an overlap period before any substitution, at the vendor’s cost. And cap the number of substitutions over the term.

The cap is the one that matters. Without it, replacement becomes routine and the knowledge you paid to build leaves in pieces without anyone ever deciding that it should. Our standard is at most one planned substitution per person per twelve months, a two-week overlap, and no substitution at all during the final month of a delivery phase.

Watch how a vendor reacts to this. Those who staff stable teams agree without discussion; those who resist are telling you something useful about how they operate, at no cost to you.

Step 6 — Write the exit before you need it, then rehearse it

Exit clauses are usually written in a hurry, in generic language, by people who assume they will never be used. Then they are used, under time pressure, by people who did not write them.

A workable exit provision lists what you receive, in what state, and within how many days. Not just the repository: the repository with its full history, the deployment configuration, an inventory of environment variables and secrets locations, the runbooks for anything operational, and a handover session with the people who actually did the work — named, not “a representative”.

And then the provision that costs almost nothing and that virtually nobody includes: rehearse it once, while the relationship is healthy. Pick a small component, have the vendor hand it over to your team as if the contract were ending, and see what is missing.

We have done this on four engagements. Every single time it surfaced something — an undocumented deployment step, credentials held by one person, a build that only worked on one machine. Discovering that during a planned one-day rehearsal is a minor inconvenience. Discovering it during an actual exit, with a deadline, is a serious problem.

Step 7 — Review two numbers every month

Long reporting packs get produced, circulated and unread. Two numbers, reviewed in a fifteen-minute conversation, work better than a dashboard nobody opens.

The first is the proportion of committed items delivered within the agreed period. Not velocity, not story points — a simple ratio. When it declines two months running, something has changed and it is nearly always people rather than complexity.

The second is the number of items returned after being marked done. This measures whether your definition of done is real. A rising number means the definition has quietly drifted, and it is far cheaper to correct in month three than in month nine.

The three mistakes we made ourselves

Negotiating price first. On our first two engagements we agreed a rate, then tried to specify the work. Every subsequent clarification was received as an attempt to extract more for the same money, and the vendor was not wrong to see it that way.

Accepting vendor-owned infrastructure to save a week. Twice. Both migrations cost more than the setup time we saved, and one of them exposed the fact that our production configuration existed only inside a CI system we did not control.

Treating the exit clause as legal boilerplate. We had a good exit clause on an engagement that ended badly, and it was still painful, because nobody had ever tested whether the deliverables it described could actually be produced. Now we rehearse.

For teams working across the region, the operational shape of these agreements varies more than the legal shape. Colleagues at HireDeveloper.sg report that Singapore engagements tend to fail on change-handling rather than on ownership, while the team at JapanDev finds that named-people provisions carry far more weight in Japan than any service-level number. If you are still deciding what to build before deciding who builds it, our guides on how to build a fintech app in the UAE and how to build a marketplace app set out the scope questions worth answering first.

Frequently asked questions