Portfolio Website Handoff Checklist: What to Test Before Approval

Test a delivered portfolio website, confirm ownership and record specific fixes before accepting the handoff.

A polished homepage screenshot is not a complete website handoff. Before approving a portfolio, check the agreed pages, the visitor's path and the files or access you were promised. Separate defects from new requests so both sides know what remains to be done.

Use the agreed scope as the reference. Do not silently turn a source-file delivery into a demand for ongoing hosting, or treat a preview link as a permanent public website.

Compare the delivery with the order

List the promised deliverables and mark each as received, missing or requiring clarification. Include pages, language versions, mobile presentation and any specifically agreed integrations.

Record whether the supplied URL is a preview or the intended final address. If it is temporary, ask what happens after it expires. If source files were promised, verify that you received the correct project and usable instructions. Hosting and source delivery are separate responsibilities.

Walk through the visitor's path

Open the site on a phone and a desktop. Read a project, follow its demo link and try the primary contact action. If there is a form, send a harmless test and confirm it reaches the agreed destination.

Check project names, your role, captions and public contact details. Try the links a visitor is likely to use rather than only clicking the navigation. Webflow's launch checklist is a broader reference; your acceptance list should stay tied to the work you purchased.

Verify ownership and practical access

Ask who controls the domain, hosting and editing account. Test the access that was included in the agreement. An invitation email is not the same as successful access to the right site.

Use the platform's supported ownership or permission process rather than exchanging personal passwords. Where files are delivered instead of an editor account, confirm how the site is opened, built or deployed. If that work is outside the purchase, identify who will handle it before assuming the website is live.

Report fixes in a form someone can act on

A useful feedback item contains a location, what happened and the expected result. For example: “On the project page on my phone, the contact button opens the old email address; it should open the agreed public address.”

Feedback typeHow to handle it
Agreed link points to the wrong destinationRequest a correction
Promised page is missingReference the agreed scope
You now want another languageAsk for a scope and price change
You prefer a new layout after approvalDiscuss a new request rather than assuming inclusion

Use any review window stated in your agreement; do not assume a universal free revision period.

Close the handoff with an explicit record

Confirm what was accepted, what remains open and who handles later updates. Save the delivery files and instructions in a place you control. The companion maintenance guide helps assign ongoing responsibilities.

A good handoff means you can use the delivered work as agreed and know what happens next. It does not require inventing extra tests or features after the purchase.

Use the portfolio maintenance guide to assign responsibility for edits, renewals and faults after acceptance.

To check what Agent.Space currently offers, visit its service marketplace. Confirm that a suitable service is listed and read its delivery scope before ordering.