Outsourcing Contract Disputes Start With the Sentence Nobody Wrote

After you have argued over a contract a few times, the pattern gets obvious. The clauses that cause trouble are never the densely written ones. They are the line nobody wrote — the thing both sides considered so obvious it did not need saying, until it turned out each side considered the opposite obvious.

What follows are the situations that made us rewrite our contract sentence by sentence. They are described as types, with no specific project pointed at. What to add clause by clause is set out in the outsourcing contract checklist.

A few weeks after delivery, a message arrives: "we are inside the free warranty period, so this should be covered too." You open it and it is a feature that was never in the original scope. There is no bad faith in this. They started using the product, a need appeared, and the warranty period was still running, so of course it seemed covered.

A defect is the product not behaving the way the agreed requirements say it should. But however well you write that sentence into a contract, it has no force if "the agreed requirements" exist nowhere in writing. It becomes memory against memory, and in that fight the side with more to lose usually loses.

We now attach the feature list from the quoting stage directly to the contract as an appendix. Not an elaborate specification — one line per screen. Even that ends the conversation with "this is on the list, that is not." What to write and how is covered in the acceptance test checklist.

The most common reason development stalls is not that the vendor stopped working. It is that a question went unanswered. An admin account was requested and the person who has it is on leave; a settlement rule needed confirmation and internal approval has not come through. Two weeks pass, and on the calendar those two weeks are recorded as development delay.

This is not an argument for blaming clients. It happens because no standard exists. Our contract now includes a clause asking for a reply to confirmation requests within three business days, and a clause stating that if no reply arrives, the client is deemed to have agreed to the approach we proposed. It looked unfavorable to the client at first, and in practice it was the opposite: because the contract says what is owed by when, work moves inside the client's organization too.

Adding one line to the delivery clause — "delays caused by client-side missing materials, late responses, or requirement changes are excluded from the delivery schedule" — settles about half of this problem.

When the contract does not say when copyright transfers, this standoff shows up at the end. The client says payment follows delivery; the vendor says delivery follows payment. Neither is wrong, which is what makes it hard to unwind.

Our contract states that the economic copyright transfers on full payment of the contract amount, and remains with the developer until then. (Under Korean copyright law, economic rights transfer by agreement while moral rights stay with the author.) That can feel uncomfortable from the buyer side, but negotiating to invert it is less productive than making the final payment easy to release. Concrete acceptance criteria mean acceptance finishes in days, acceptance finishing releases the balance, and the balance releases the source. What jams this up is almost always the absence of a definition of what passing acceptance means.

One more thing. General-purpose modules and frameworks the vendor already owned do not transfer wholesale. What transfers is the part newly built for this project; for the pre-existing parts you receive a license to use them. If that distinction is not in the contract, "you said we would get all of it" comes later.

The classic example of something absent from the contract surfacing mid-project. There is no bad intent behind it — sitting together feels faster, and sometimes it genuinely is.

The problem is that requesting on-site presence at fixed-price rates does not add up. A quote calculated on the assumption of remote delivery loses roughly half its effective rate once commuting and waiting time are attached. If a project truly requires on-site work, that is not fixed-price contracted work (도급) but an on-site staffing arrangement, and it runs on an entirely different rate structure.

Our scope clause now states that work is performed remotely and that presence at the client's premises is not included. One line, and the conversation never starts.

Requirements changing mid-build is natural. You start making something and discover the original idea was wrong, and changing it then is the right call. The problem is when the change is tacitly assumed to be free.

One small change genuinely can be absorbed. Five or ten of them and the project quietly goes into the red, and from that point the vendor gets slower to respond. The client, not knowing why, starts feeling that things have gotten sluggish lately. That silent spiral is what wrecks the relationship.

The clean approach is to set the price of change at contract time — an hourly rate, or a price per added screen. Then nobody has to re-quote or read the room every time something changes. The client can also decide knowing exactly what a given change costs. The calculation method is set out in change request pricing.

On small projects, people often skip the contract because bringing it up seems likely to make the relationship stiff. We did the same early on. In practice it is the reverse: the absence of a contract is what damages the relationship, not its presence. When it is written down, saying "that falls outside scope, so it needs a separate quote" is an administrative note; when it is not, the same sentence sounds like stinginess.

At Freesi the contract is generated automatically once the quote is confirmed and executed by e-signature, so there is never a moment where someone has to ask "shall we sign a contract?" Why each clause reads the way it does is broken down in the outsourcing contract checklist, which you are welcome to use as a comparison when contracting with anyone else.

One caveat: this reflects field experience and describes Korean contracting practice — it is not legal advice. For large contracts, or any involving intellectual property or personal data, have a lawyer review them.