How to Accept Software Development Work: A Client Checklist

Software is ready for acceptance when the agreed user flow works predictably—not merely when a new button appears. Acceptance lets you verify the result before payment and keeps the discussion focused on observable behavior.

Start with acceptance criteria

For each task, write who performs the action, what they see, which data is created, and what counts as an error. A good criterion can be tested without the person who wrote it.

• the page works in supported browsers;
• data is saved and remains after refresh;
• invalid input produces a clear message;
• users without the right role are denied access;
• a notification or integration fires once;
• the change does not break a connected flow.

Test in this order

Check the delivered package

Ask for the source code, the relevant branch or release, changed areas, startup instructions, and known limitations. A database project needs migration and backup information. An integration needs a test method for retries and external-service failures.

Record issues clearly

Each issue should include steps, expected behavior, and actual behavior. Separate blockers, important mismatches, and ideas for later. This tells the developer what must be fixed before acceptance and what can be planned separately.

Do not change the criteria after delivery unless it is a new agreed task. If requirements changed, create a new estimate and timeline.

When independent review helps

It is useful for payments, accounts, permissions, medical or financial data, and any project another developer will take over. For a complex system, start with audit and support or request an independent review.

How a freelancer should prepare delivery

Acceptance starts before you send the final link. Compare the result with the brief, remove test data, check a clean account, and prepare a change list. If a requirement is deferred, state it clearly so the client has no false expectation.

Delivery package

• a link to test or production environment;
• a short recording of the main flow;
• completed items and known limitations;
• test accounts for different roles;
• startup, release, and rollback instructions;
• source-code link and important-change summary.

Show not only the result but also how it can be checked. This reduces subjective edits and helps close the stage faster.

How to handle extra changes

If the client asks to correct a mismatch with the agreed brief, it belongs to acceptance. If they change a rule, add a screen, or request another flow, it changes scope. Reply with two parts: what you will fix within acceptance and what needs a new estimate.

Review window and payment

Agree on a review period and a single feedback format. For example, the client sends one list within three business days, and the freelancer responds within the agreed time. This is better than endless one-item messages.

For several stages, link payment to verifiable outcomes. The freelancer is paid for completed work, while the client sees an intermediate result before paying for everything.

Save the final version and handover date after acceptance. This helps separate warranty fixes from a new change requested weeks later.

The final question before payment

Ask whether another person could repeat the verification without help from the author. If not, a criterion, test data, or an instruction is missing. Add it to the delivery package before closing the stage.

This discipline helps both sides. The client receives a repeatable result, and the freelancer gets a clear boundary between fixing their work and taking on a new task.