In software, the contract is decided by who owns the code.

Every other clause in a development agreement is negotiable in the ordinary way. IP is not: it is binary, permanent, and it determines what the client can do with the thing you built and what you can reuse on your next project. Settle it explicitly, then deal with acceptance, which is the second most common failure.

What goes wrong in this trade

Five things this document has to handle.

IP ownership and reuse	Full assignment means you cannot reuse your own frameworks. Assignment with a carve-out for pre-existing components, licensed to the client, is the usual workable position.
Open-source components	Licences flow through to the client. Copyleft licences can have real consequences for a proprietary product. Disclose what you are using.
Acceptance testing	Untestable criteria mean the final payment has no trigger. Define tests, a reviewer and a window.
Post-launch expectations	Whether bug fixes are warranty work or billable, and for how long. The most common unbudgeted cost in the category.
Third-party dependencies	Hosting, APIs, licences. Who contracts with them and who pays.

The clauses

What to put in, and what each one is for.

Specification and scope

What is being built, by reference to a specification document at a named version.

IP ownership

Deliverable code assigned on payment, with pre-existing components and general know-how retained and licensed.

Open-source disclosure

That open-source is used, and a list or a process for approving licences.

Acceptance testing

Named tests, a named reviewer, a review window, and deemed acceptance absent written rejection.

Warranty period

A period after acceptance during which defects are fixed at no charge, and what counts as a defect rather than a change.

Maintenance and support

Separate from the build. Response times, hours, and what is included.

Source code and escrow

Where the code lives, when the client gets it, and whether escrow is required.

Data protection

Who is controller and processor, and what happens to data on termination.

Change control

How scope changes are priced and approved.

Commercial norms

How development work is usually priced

Fixed price	Needs a tight specification and real acceptance criteria. Risk sits with you.
Time and materials	Needs a cap or a regular reporting rhythm. Risk sits with the client.
Sprint or capacity	A fixed amount of capacity per period. Common, and needs a clear definition of a sprint's output.
Maintenance	Priced separately after the warranty period, usually monthly.

Worth its own section

Acceptance testing is where fixed-price projects die

A fixed-price build with acceptance defined as client satisfaction is an open-ended commitment with a closed-ended price. Write the tests into the agreement or into a schedule attached to it: named scenarios, expected results, a named reviewer, a review window in business days, and deemed acceptance if nothing is said. Then separate a defect, which you fix under warranty, from a change, which goes through change control. Projects that do not draw that line spend their last month arguing about whether a request is a bug.

One sentence in

This much is enough.

Build the Northwind customer portal to spec v1.2, fixed price $96,000 across three phases, code assigned on payment with our component library licensed rather than assigned, acceptance per the test schedule with a 10 business day review, 90-day warranty then monthly maintenance quoted separately.

Out comes the agreement with the clauses above, the figures computed from your catalog, the signers set and the signature fields placed. Send it as a link and they sign on a phone on site. Once signed, the terms are read back so a renewal or a defects period does not surprise you.

Questions people actually ask

Straight answers.

Who owns the code in a development agreement?

Whatever the agreement says, which is why silence is expensive. The common workable position is that deliverable code is assigned to the client on full payment, while the developer retains pre-existing libraries, frameworks and general know-how and licenses anything of theirs embedded in the deliverable.

What should acceptance testing look like?

Named test scenarios with expected results, a named reviewer, a review window in business days, and deemed acceptance if nothing is said. Acceptance defined as the client being satisfied turns a fixed price into an open-ended commitment.

What is source code escrow and do I need it?

A third party holds the code and releases it to the client on defined triggers, usually your insolvency or a failure to support. Clients who depend on the software commercially sometimes require it. It is less common than it was, since most clients now simply take the repository.

Is post-launch support included?

Only if you say so. Define a warranty period during which genuine defects are fixed at no charge, separate that from changes, and price ongoing maintenance separately. Leaving it unstated is the most common unbudgeted cost in the category.

General guidance for this trade, not legal advice. Requirements vary by state and by the work, particularly around licensing, insurance and lien rights. Have your standard agreement reviewed once by a lawyer who knows your jurisdiction, then produce every job from it.

Other trades