Project Sign-Off Template for Small Software Jobs

Editorial team Kleiner Auftrag Updated 5 min read

Short answer: A project sign-off records that you checked the delivered work and accept it as essentially meeting the agreement. It should name the basis (quote or order), mark each acceptance criterion passed or failed, record open defects with a fix-by date and reserve your rights regarding them. Sign-off often triggers final payment.

Hand with wristwatch writing notes in a notebook next to a laptop
Photo: Alejandro Escamilla, CC0, via Wikimedia Commons

Plenty of small software jobs end without anyone actually saying “done”. The developer writes “it’s live”. You glance at it, it looks fine, the invoice arrives, you pay. Three weeks later the confirmation email turns out not to reach anyone on a phone. Was it always like that? Is fixing it a new job or part of the old one? Nobody really knows any more.

Sign-off answers those questions before they come up. On a two-hour job it’s half a page. On a plugin or an integration, maybe a full one.

What signing off actually does

What legally follows from sign-off depends on your contract and where you and the developer are based. Three things are common in practice.

Payment. Many small-job agreements make the final payment due on sign-off. If yours does, signing is the moment you release the money.

Open defects. Problems you list at sign-off stay on the developer’s to-do list. Problems you knew about and didn’t list are much harder to raise later. Under German law, for instance, accepting work despite a known defect costs you the right to have that defect fixed or to reduce the price, unless you reserve those rights at acceptance.

Burden of proof. Before sign-off it’s on the developer to show the work is right. Afterwards it tends to be on you to show a defect was already there.

Neither the UK nor the US has a statutory acceptance procedure for software work comparable to the German one described below. What counts is what you agreed. That’s exactly why a short written sign-off helps: it becomes the record of what was accepted, when, and with which reservations.

If your developer is in Germany

If your developer is based in Germany and the contract falls under German law, acceptance (Abnahme) is a formal step with real consequences. Section 640 of the Civil Code (BGB) obliges the client to accept work that conforms to the contract, and acceptance cannot be refused for insignificant defects. Payment falls due on acceptance under § 641.

The rule that catches foreign clients out is deemed acceptance. Under § 640(2) BGB, once the contractor has finished and set you a reasonable deadline, the work counts as accepted unless you refuse within that period and name at least one defect. Consumers are only bound by this if they were told about the consequence in text form along with the request. To a business client, an email saying “please sign off by Friday” is not a formality. Miss it, and you’ve accepted.

How deemed acceptance plays out under German law
  1. Day 0Developer reports the work as finished and sets a reasonable deadline for acceptance.
  2. Within the deadlineYou test. Found a problem? Refuse acceptance in writing and name at least one defect.
  3. Deadline passesNo response, or a refusal without a named defect: the work counts as accepted.
  4. After acceptanceFinal payment is due (§ 641 BGB), and you now have to prove any defect existed at delivery.

Source: § 640(2) BGB

Copyable project sign-off template

The template below is an example for small jobs, not reviewed contract wording. With large sums or a dispute, have a lawyer look at it.

PROJECT SIGN-OFF

Client:            [name, company]
Developer:         [name, company]
Work:              [short name, e.g. "Shopify to Xero order sync"]
Basis:             Quote / order confirmation dated [date]
Tested on:         [date], environment: [live / staging, devices, browsers]

1. Acceptance criteria
   No. | Criterion (from the agreement)                | Pass | Fail
   1   | ...                                            | [ ]  | [ ]
   2   | ...                                            | [ ]  | [ ]
   3   | ...                                            | [ ]  | [ ]

2. Open defects
   No. | Description (steps, expected, actual)          | Major? | Fix by
   D1  | ...                                            | y / n  | [date]

3. Handover
   [ ] Source code / repository access   [ ] Documentation / change notes
   [ ] Temporary access removed or disabled

4. Outcome
   [ ] Accepted, no open defects
   [ ] Accepted. Rights regarding defects D1 to D... are reserved;
       they will be fixed by [date].
   [ ] Not accepted due to major defects: D...

Client (name, date)                     Developer (name, date)

Keep the criteria in section 1 identical to the ones in the quote, word for word. If the quote said “three test emails arrive within five minutes”, the sign-off should say the same, not a looser paraphrase.

The reservation line is the heart of it. It protects your position on defects you know about while still telling the developer that the job is, in substance, done.

Major or minor: where to draw the line

Contracts and laws rarely define “minor” precisely. On small software jobs one practical question helps: can you use the work for its purpose while the defect is still there?

Slightly misaligned button on one device? Minor. The form still does its job. Messages from the form never arrive? Major, however good it looks. So is an integration that sends 98 of 100 invoices and silently drops two, because you can’t rely on it.

That call gets much easier if you agreed testable acceptance criteria upfront. At sign-off you work through the list instead of debating impressions. Describe every defect you find the way you’d write a bug report: steps, expected, actual.

Running the sign-off in half an hour

Book real time for testing. Fifteen minutes clicking around on your own laptop isn’t a sign-off. Here’s what works without becoming a project of its own:

Sign-off in 30 minutes
  • Check every agreed criterion individually and tick it off
  • Test on a smartphone and a desktop browser
  • Re-test business-critical flows: checkout, contact form, login
  • Write down defects with steps and a screenshot
  • Check handover items: code, docs, access
  • Confirm the outcome in writing, reserving rights on known defects

The third item matters because small changes love side effects. Tweaking the theme can affect the checkout, which was never part of the job.

Partial sign-off and payment without sign-off

If a job splits cleanly into parts, say first the plugin and then the connection to an outside service, signing off each part separately can make sense. Each part is tested and accepted on its own, then paid. The developer gets paid sooner, and you find out sooner whether things are heading the right way. Partial sign-offs have to be agreed upfront, ideally in the order confirmation, with the criteria for each part listed separately so nobody argues later about which test belonged to which stage. Under a day of work, it’s rarely worth it.

Watch out for the quiet version of sign-off. Using the work for a while without complaint and paying the invoice without comment can be read as acceptance. If a known defect is still open when you pay, add one line to your payment email saying the payment is made subject to that open defect. Ten seconds, well spent.

Sign-off by email: sample wording

For a job worth a few hundred dollars, nobody prints forms. An email does the job if it covers the essentials:

Hi [name],

I tested the change on [date] on [device/browser].
Criteria 1 to 3 from your quote dated [date] are met,
and I accept the work.

I reserve my rights regarding the following defect:
D1: [description]. Please fix it by [date].

Thanks,
[name]

After sign-off, disable accounts the developer only needed for this job. Our guide on how to share passwords with a developer includes a revoke checklist. If code was delivered, now is the time to confirm what rights you hold. The article on who owns the code explains what to look for.

If every sign-off turns into a negotiation, the problem usually isn’t the sign-off but the brief at the start. For larger builds, it’s worth talking to a software development studio early, so acceptance criteria are part of the plan from day one rather than an afterthought.

For the job you have running now: copy the template or the email, fill in the criteria from your quote, and block half an hour in your calendar before the developer’s deadline runs out.

Questions people ask

Does a sign-off have to be signed on paper?

For small jobs, rarely. An email that states you accept the work and lists any open defects is usually enough, as long as both sides can later show what was said and when. Check your contract, though, in case it requires a particular form.

What is deemed acceptance?

It's a clause, or in some countries a legal rule, under which the work counts as accepted if you don't respond within a set period or don't name a defect. In Germany, § 640(2) of the Civil Code works this way for business clients once the contractor has set a reasonable deadline.

Can I refuse to sign off because of a small bug?

Usually you shouldn't, and under German law you can't refuse acceptance for insignificant defects. Accept the work, list the bug as an open item with a deadline, and reserve your rights for it in writing.

What if I find a bug after signing off?

Defects you didn't know about at sign-off can still be raised under your contract or local law. You may have to show the defect already existed at delivery, though. The more carefully you test before signing, the less often you end up there.