Software development agreement, Harbourpoint booking platform
Software development agreement with sprints and an acceptance test
Custom software goes wrong in the space between delivered and accepted, where one side thinks a sprint is finished and the other is still writing a list. This agreement fixes a ten business day acceptance window against criteria written before the sprint started, and assigns the intellectual property sprint by sprint as each invoice is paid.
The document, page by page
Every page as it renders and as it prints, with nothing summarised. Read the wording before you reuse it.
Section by section
What each section is for, so you can keep the ones you need and drop the rest.
- Cover and contents
- A contract cover naming the project, then a contents list to the ten sections.
- Parties and key terms
- Developer and client, then the total fee, the sprint count, the acceptance window and the warranty.
- 1. What is being built
- The booking platform, its integrations, what is out of scope, and the non functional requirements.
- 2. Sprints and delivery
- Six two week sprints with dates and fees totalling $92,400, and the product owner obligation.
- 3. Acceptance testing
- The ten day window, defect handling and retest, and what happens when the client goes quiet.
- 4. Changes to scope
- How a change request is answered and approved, and the rates it is charged at.
- 5. Fees and payment
- Invoicing on acceptance, third party cloud costs, and suspension for overdue invoices.
- 6. Intellectual property
- Assignment on payment, the developer's pre existing libraries, and attribution limits.
- 7. Source code escrow
- The client owned repository and everything kept in it alongside the code.
- 8. Warranty and support
- The 90 day warranty scope and what happens if no support agreement follows.
- 9. Data, confidentiality and security
- Patient data handling, security practices, and the four hour breach report.
- 10. Ending the agreement
- Notice at a sprint boundary, the handover and free transition hours, and the liability caps.
- Signatures
- A block for the developer and one for the client.
Clauses in this document
- Acceptance testing clause: deciding when the work is done
- Change control clause: requesting, pricing and approving a scope change
- Cyber security clause: the controls a supplier must keep
- Data breach notification clause
- Data protection clause
- Delivery clause: where, when and how the handover happens
- Open source software clause: what a developer promises about code it did not write
- Reporting obligations clause: what the supplier must tell you, and when
- Standard of care clause: how good the work has to be
How to adapt this agreement
For a fixed scope project rather than sprints, replace the sprint table with deliverables and milestone payments and tighten the change clause, because a fixed price only holds when the scope does. For a staff augmentation arrangement, delete the acceptance section entirely and replace it with named people, day rates and a notice period, since there is nothing to accept. For a product without regulated data, cut clause 9 back to ordinary confidentiality and a security schedule, and move the four hour breach report to 24 hours, which is realistic when there is no notifiable data breach obligation sitting behind it.
What makes this document work
Acceptance is tested against something written first
Clause 3.1 gives 10 business days to test each sprint against criteria agreed before the sprint started, and an info callout says why that ordering matters. A defect gets fixed in 10 days, and something that works but is no longer wanted is a change, not a defect.
Nobody pays ahead of accepted work
Each of the six sprints is $14,000 and is invoiced only on acceptance, with no deposit at all. The table adds to $84,000 before GST and $92,400 after it, so the client can see the whole commitment and the cash flow in one place.
The code never leaves the client's hands
Clause 7.1 puts the repository in the client's own account from sprint 1 with the developer as a contributor. Because the client already holds the code, the agreement can honestly say a third party escrow agent is unnecessary rather than pretending to offer one.
Questions people ask
What should a software development agreement include?
The scope including integrations and non functional requirements, the delivery plan and fees, an acceptance process with a deadline, how changes are priced, when intellectual property transfers, where the code lives, warranty, data and security obligations, and what happens at the end.
What is acceptance testing in a software contract?
A defined window in which the client checks a delivery against agreed criteria and either accepts it or lists defects. Here it is 10 business days, defects are fixed within 10 more, and silence for the whole window plus a reminder becomes acceptance.
When does the client own the code?
On payment, not on delivery. Clause 6.1 assigns copyright in the software, the database schema, the designs and the documentation for each sprint when the invoice covering that sprint is paid in full, and licenses it to the client for testing in the meantime.
Is source code escrow necessary?
Only when the developer holds the code. This agreement puts the repository in the client's own account from the first sprint with build instructions and a runbook alongside it, which achieves what escrow is for without the cost or the release conditions.
How are change requests handled?
Either side can raise one. The developer responds within three business days with the effect on cost, on sprint dates and on anything already built, and work starts only on written approval. Nothing is charged for a change response the client does not approve.
Who is responsible for patient data during development?
Both, with the developer bound by clause 9. It uses de identified or synthetic data in development wherever possible, never copies production data to a laptop, accesses production only with written approval through a logged account, and reports a suspected breach within four hours.
Build your own in about a minute
The button below opens the generator with this use case already described. Change the wording to match your own, generate, then edit anything you like.
Make my software development agreement with sprints and an acceptance testOther document examples
Videography contract template with shoot days and a delivery table
Video work is quoted in days and judged in files, and the two rarely match up in writing. This contract sets out the crew hours for each shoot day, lists nine deliverables with a length, a format and a date, and answers the two questions clients ask last: who gets the raw footage, and can the music be used in an ad.
Web design contract template with milestones and revision rounds
Website projects rarely fail on design. They stall because the content never arrives and nobody wrote down what happens next. This contract dates every milestone on both sides, deems a stage approved if the client goes quiet, and moves the launch by a day for every day the copy is late.
IT support services agreement with response times by priority
Managed support is sold on a monthly fee and judged on how fast the phone gets answered when nobody can work. This agreement grades every ticket into four priorities with a published response and resolution target, credits the fee when the target is missed, and writes down exactly what the provider hands back on the way out.
Want the steps in the builder? Read Create a document with AI, then Layout, spacing and page breaks. For everything this generator can do, see the document maker.
Written and checked by the OneCraft team. Last checked .