What is acceptance?

Both sides want opposite things, and both are being reasonable

The client is buying something they cannot fully evaluate in advance and cannot easily fix themselves. They want strict criteria, real testing time, and no obligation to pay for something that does not work. That is not a trick. It is what a careful buyer does.

The developer is selling work whose exact shape nobody knows until it is built. They want criteria they can actually satisfy, a bounded review period, and the ability to fix a small problem without the whole engagement being held hostage. Also not a trick.

You will not resolve that tension by finding a midpoint on how strict the criteria are. You resolve it by making the criteria specific — which serves both sides — and by making the process fair, which is where most of the protection lives.

Write criteria you can actually satisfy

The instinct on a fast-moving project is to keep the deliverable description loose so you have room to move. This is backwards, and it is the single most expensive mistake in these contracts.

"We will work together on the payments integration" sounds flexible. What it means is that there is no defined moment at which you are finished, so the client can keep asking, and there is no defined thing you delivered, so you cannot point at it when you invoice. Vagueness does not create room. It creates an argument you are structurally positioned to lose, because you are the one asking for money.

The problem is real, though: you genuinely cannot describe the output in advance. Nobody can. You do not know exactly what you are building until you have built it.

So do not specify the output. Specify the constraints you control.

• ✓Where the code lands — which repository, which branch, merged via which process.
• ✓How it is delivered — a pull request that passes CI, a tagged release, a deployed environment they can reach.
• ✓What proves it works — a named test suite passing, a documented endpoint returning a documented response, a migration running clean against a copy of production.
• ✓What "reviewed" means — who reviews it, in what timeframe, and how their response gets recorded.
• ✓What is explicitly out of scope — the browsers you are not supporting, the loads you are not designing for, the integrations that are someone else's.

Every item on that list is objectively checkable and entirely within your control. None of them require you to predict what the code will look like. This is what specificity means for software, and it is why a good SOW makes both sides safer rather than trading one side's safety for the other's.

Deemed acceptance: the clause that stops the silence

The most common way a developer does not get paid is not rejection. It is nothing at all. The client gets busy, the reviewer goes on leave, priorities shift, and your deliverable sits unacknowledged. If payment is tied to acceptance and acceptance requires an affirmative act, you can wait forever.

Deemed acceptance fixes this. The deliverable is treated as accepted unless the client gives written notice of rejection within a defined window — ten to fifteen business days is typical — and that notice must state the specific non-conformities rather than general dissatisfaction.

Two requirements do the work here. The window converts silence into acceptance. The specificity requirement converts "this isn't what we wanted" into a list you can actually respond to. A rejection that does not identify what failed is not a rejection you can act on, and your contract should say so.

The right to cure

A client should be able to reject work that does not meet the spec. They should not be able to use a small defect as grounds to walk away without paying for the rest.

A right to cure means a valid rejection opens a repair window rather than ending the engagement. You get a defined period to fix the identified non-conformities and resubmit. Acceptance runs again against the same criteria — not against new ones, which is the failure mode to watch for.

Two guardrails worth having:

1. 1)Re-review is limited to the original criteria. Otherwise each cycle attracts new requirements and you are on a treadmill.
2. 2)Partial acceptance is possible. If four of five deliverables pass, those four are accepted and payable. One failing component should not freeze the whole invoice.

Warranty: fix a window, not forever

Acceptance closes out delivery. Warranty covers what happens afterward, and it is where open-ended obligations hide.

Be careful about warranting performance indefinitely. Browsers update. Packages deprecate. Runtimes ship breaking changes. Third-party APIs get retired with ninety days' notice. A promise that software will keep working is a promise about a world you do not control, made to someone who is not paying you to maintain it.

The alternative that holds up: for a defined period after acceptance — thirty days is a common starting point — you will fix, at no additional charge, defects showing that the delivered work does not conform to the agreed specification. After that, maintenance is a separate engagement with its own scope and its own invoice.

Note what that does. It gives the client real recourse for genuine defects. It does not put you on the hook for a dependency someone else broke in month eight.

Tie the money to the moment

Acceptance mechanics only matter if payment is attached to them properly:

• ✓Something up front. A deposit or a first-milestone payment before substantial work, so you are not financing the project.
• ✓Milestones tied to acceptance events, not to calendar dates that can slip for reasons on their side.
• ✓Net terms that start on acceptance — including deemed acceptance — rather than on some later invoice-approval step you cannot see or trigger.
• ✓Expenses handled separately from deliverable acceptance. A disputed deliverable should not hold up reimbursement of a cloud bill you already paid.