Do not publish a contractor project photo merely because it is in the company phone, shared drive, CRM, or customer message. Before a photo or case study goes live, the business should be able to show who created the material, what use was authorized, which people and property details were reviewed, which claims the evidence supports, what was edited, who approved the final presentation, and what happens if a correction or removal request arrives.

Project proof is useful when it helps a prospective customer understand the work, constraints, process, and fit. It becomes risky when a polished gallery silently turns an unidentified photo into a claim about ownership, location, scope, performance, or customer endorsement.

This checklist gives Canadian contractors and website teams a publication workflow for project photos, before-and-after comparisons, customer quotations, and case studies. It is practical guidance, not legal advice. Copyright, privacy, contract, employment, consumer-protection, and professional rules depend on the facts and jurisdiction. Have qualified counsel review the permission language and any uncertain use.

Decide what the evidence must help a customer understand

Start with the customer decision, not the number of photos available. A project page may need to demonstrate:

  • the type and scale of work the contractor accepts;
  • the condition or constraint the project addressed;
  • the steps visible to a customer during delivery;
  • material, finish, access, or sequencing choices;
  • the difference between cosmetic and structural work;
  • how the contractor coordinates a multi-stage project; or
  • whether the project resembles the visitor's situation.

Write one sentence describing the purpose. For example:

Show how a dated exterior was prepared, repaired, and refinished while preserving the distinction between visible work and performance claims that require separate evidence.

That purpose controls the shot list, captions, facts, permissions, and page destination. It also prevents a common failure: publishing a generic gallery that looks impressive but leaves the reader unable to tell what the contractor actually did.

Choose the right content type:

| Content type | Best use | Minimum evidence | | --- | --- | --- | | Service-page image | Show a representative process, material, or completed result | Rights, relevance, accurate caption, privacy review | | Project gallery | Show several approved examples without a detailed narrative | Rights and permission record for every asset | | Before-and-after comparison | Show a visible change under reasonably comparable conditions | Verified sequence, scope, edit record, careful caption | | Case study | Explain starting condition, decisions, work, and supported outcome | Source notes, roles, dates, approvals, limitations | | Customer quotation | Preserve the customer's own approved words | Exact text, attribution scope, channel and duration |

The contractor website design checklist explains where project evidence fits within the wider service architecture. This resource owns the narrower decision of whether a specific project asset is ready to publish.

Separate the rights chain from customer permission

Several permissions may apply to the same image. Do not collapse them into one “approved” checkbox.

Canada's copyright guidance explains that an author or creator is generally the first copyright owner, subject to exceptions, and that owning a physical object does not automatically include copyright in the photograph of that object. The person who possesses the file or paid for the project may therefore be different from the person or organization that controls use of the image.

Record who captured or created each asset:

  • owner or employee;
  • independent photographer or videographer;
  • subcontractor or supplier;
  • customer;
  • architect, designer, engineer, or manufacturer;
  • previous website provider; or
  • stock-media or platform licensor.

Then record the basis for use: ownership, employment terms, written assignment, licence, platform terms, or another reviewed authorization. If a photographer delivered files, confirm what the agreement permits. A download link, invoice, or possession of high-resolution files does not by itself describe website, social, advertising, cropping, adaptation, sublicensing, or indefinite use rights.

Project, property, and relationship authorization

The right to reproduce a photo does not answer whether the contractor may identify the customer, property, project, address, testimonial, or commercial relationship. Obtain a separate, documented publication decision from the appropriate person or organization.

The approval should describe, as applicable:

  • which specific photos, video clips, words, logos, and project facts are covered;
  • whether the customer or business may be named;
  • whether the municipality, neighbourhood, street, or exact location may appear;
  • which channels are included, such as the website, organic social, email, proposals, paid advertising, or third-party publications;
  • whether cropping, colour correction, annotation, or other edits are permitted;
  • the permitted duration and territory;
  • whether the contractor or website provider may create derivative layouts;
  • who can approve corrections; and
  • the agreed process for a future removal request.

Do not turn a service agreement's broad marketing clause into an automatic publishing decision without confirming that it is valid, understood, applicable to the assets, and suitable for the intended use. Keep the customer-facing request understandable and separate from the work acceptance form where appropriate.

Review identifiable people and property details

The Office of the Privacy Commissioner of Canada describes photographs and video of identifiable individuals as possible personal information. It also explains that organizations should identify purposes, limit collection and use, obtain meaningful consent where required, safeguard information, and provide accountability and access processes.

A project image can identify more than a face. Review:

  • customers, household members, tenants, employees, subcontractors, and bystanders;
  • children and other people who may require heightened review;
  • vehicle licence plates and branded fleet numbers;
  • street numbers, mail, courier labels, permits, invoices, and work orders;
  • alarm panels, keys, access codes, lockboxes, and security cameras;
  • family photos, school materials, calendars, screens, and personal documents;
  • distinctive interiors, valuables, collections, or accessibility equipment;
  • GPS or location metadata;
  • neighbouring properties and people; and
  • uniforms, logos, badges, or tools that identify another company.

The correct response is not always a blur. Sometimes the photo should not be used. Cropping, masking, or replacing a file may be appropriate when the removed detail is irrelevant and the edit does not change the commercial impression. Record what changed and why.

Avoid publishing minors unless there is a specific, reviewed reason and appropriate authorization. A project page rarely needs a customer or family member in the frame to prove the contractor's work.

Privacy obligations vary across Canada and can be affected by provincial law, the type of organization, the relationship, and how the material is used. Record who assessed applicability instead of inserting “PIPEDA compliant” as an unsupported approval label.

Create a project capture plan before arriving

Permission and evidence are easier to manage when the team knows what it needs before taking photos. For each project, prepare a short capture plan:

  • the project decision the future page will support;
  • the stages worth documenting;
  • required wide, medium, and detail views;
  • the safe location and time for photography;
  • people who must be notified;
  • areas and information that must stay out of frame;
  • who is allowed to capture media on the site;
  • equipment and personal protective requirements;
  • the source of project facts and measurements; and
  • the person responsible for uploading originals.

Photography must not interfere with site safety, customer privacy, contractual restrictions, inspections, or the work itself. Do not ask a worker to remove protective equipment, stand in an unsafe position, interrupt a controlled task, or stage a misleading action for marketing.

Capture context as well as finishes. A useful set might show:

  1. the verified initial condition;
  2. a constraint that shaped the approach;
  3. preparation or protection;
  4. a meaningful work stage;
  5. a detail that demonstrates the described scope; and
  6. the completed visible result.

Record the capture date, project phase, photographer, and brief factual note while the information is fresh. Do not depend on someone reconstructing the sequence months later from filenames such as IMG_4382.jpg.

Build a publication record for every asset

The following Nexxen publication record is an original decision framework, not a claim that one form resolves every legal issue. Adapt it to the business and obtain appropriate review.

| Field | Required question | | --- | --- | | Asset ID | Can the published file be traced to an original? | | Creator | Who captured or created it? | | Rights basis | What ownership, assignment, licence, or agreement permits use? | | Project authorization | Who approved publication of the project or relationship? | | Included channels | Website, social, email, proposals, ads, partners, or other uses? | | Identifiers | Which people, properties, brands, documents, or locations appear? | | Privacy decision | Publish, crop, redact, replace, restrict, or decline? | | Factual caption | What does the image actually show? | | Claim supported | Which visible or measured statement can it substantiate? | | Edit history | What was cropped, corrected, masked, annotated, or composited? | | Approval version | Which exact image, caption, quote, and page were approved? | | Approvers and dates | Who checked rights, facts, privacy, and final presentation? | | Expiry or review date | When must the permission or accuracy be checked again? | | Removal procedure | Who can unpublish the page and purge derived assets? |

Use stable asset IDs rather than personal details in public filenames. Keep the permission record private and access controlled. The public page does not need to expose an email thread, signature, home address, or internal review note to prove that the team completed the review.

An asset remains blocked when the creator is unknown, the rights basis is assumed, the identifiable-person review is incomplete, the caption cannot be verified, or the final version differs materially from what was approved.

Verify the case-study facts before writing the story

A case study should distinguish source facts from marketing interpretation. Create a fact sheet before drafting:

  • project type and broad location, at the approved level of precision;
  • starting condition and how it was established;
  • customer objective, only if authorized;
  • contractor's exact scope;
  • work performed by other trades or the customer;
  • relevant dates or phase order;
  • specified materials, products, or systems;
  • constraints and approved changes;
  • visible completed condition;
  • measurements and their source;
  • unresolved limitations or later work; and
  • names and credentials that may be published.

Do not imply responsibility for an entire renovation when the contractor completed one trade. Do not present a supplier rendering as the constructed result. Do not describe a recommended option as the option installed. If several companies contributed, label Nexxen's client's role accurately.

Separate statements into evidence classes:

| Statement | Evidence needed | | --- | --- | | “The deck boards were replaced” | Scope record and accurate project images | | “Completed in five working days” | Defined start/end points and dated project record | | “Reduced energy use by 30%” | Suitable before/after measurement and method | | “Customer chose the darker finish” | Authorized project note or customer confirmation | | “Award-winning installation” | Current award record and permission to use its name or mark | | “Best contractor in the city” | Do not publish without a defensible basis; broad superiority claims are high risk |

The Competition Bureau says materially false or misleading representations are prohibited and evaluates the general impression created by words, images, and design. Its performance-claim guidance says adequate and proper testing must precede a performance claim. A photo can support a visible condition; it usually cannot prove energy savings, durability, safety, property value, lifespan, or comparative performance by itself.

Have the relevant technical professional or claim owner review regulated, structural, environmental, efficiency, code, health, safety, warranty, and performance statements before publication.

Present before-and-after images without manufacturing a result

Before-and-after comparisons can communicate visible change quickly, but the comparison itself creates a claim. Preserve enough context to make it fair:

  • confirm which image is before and which is after;
  • use similar viewpoint, framing, and scale where practical;
  • disclose meaningful changes in lighting, weather, staging, furnishings, or season;
  • do not label a rendering or proposed design as the completed “after” image;
  • avoid filters or colour changes that exaggerate the difference;
  • retain originals and an edit history;
  • identify work outside the contractor's scope when it affects the comparison; and
  • write a caption that states what changed without implying unsupported performance.

Side-by-side images taken in different seasons may still be useful, but the caption should not invite the reader to attribute every difference to the work. A tightly cropped finished surface should not be paired with a wide initial image if the change in framing conceals relevant context.

If an image was staged for clarity, annotated, digitally cleaned, or generated from a design tool, label that treatment where it could affect the reader's interpretation. Never use generative editing to add completed work, remove a defect, change a product, or create a client project that did not exist.

Use customer words exactly and within the approved scope

A customer quotation is separate evidence. Preserve:

  • the original wording and source;
  • the date received;
  • the identity and relationship of the speaker;
  • the exact excerpt proposed for publication;
  • spelling or grammar edits, if any;
  • approved name, role, company, and location attribution;
  • included channels and duration; and
  • the approval date and record.

Do not convert private feedback into a public testimonial without authorization. Do not combine parts of different messages, write words for the customer, remove a material qualification, or imply that a quotation describes work outside the customer's actual experience.

Keep the review-request process neutral. A business should not solicit public feedback only from customers expected to be positive or make access to support conditional on a favourable review. A permission request to feature a quotation should not alter, suppress, or gate the customer's ability to give honest feedback elsewhere.

The Competition Bureau's deceptive-marketing guidance specifically cautions against unauthorized or distorted testimonials. A sincere quotation is not automatic proof of a technical performance claim.

Protect originals and document every derivative

Use an asset workflow that separates evidence from publishing files:

  1. Preserve the original file in restricted storage.
  2. Assign a stable internal asset ID.
  3. Record the creator, capture date, project, and source.
  4. Create a working copy for crop, exposure, colour, redaction, and annotation.
  5. Record material edits.
  6. Export web derivatives at the sizes and formats the design needs.
  7. Link every derivative back to the original and permission record.
  8. Approve the actual derivative, caption, alt decision, and page context.

Do not overwrite the original with a compressed or edited version. Limit access to originals because they may contain higher-resolution personal information, documents, or metadata that is not visible in the public crop.

Review embedded metadata before publication. Remove location and other unnecessary personal information from public derivatives when it is not part of an approved purpose. Preserve creator and rights information where appropriate and accurate. Google documents optional structured data and IPTC approaches for communicating image creator, credit, and licensing information, but adding metadata does not create rights the business does not have.

Public filenames should be descriptive enough for asset management without exposing a customer name, full address, phone number, work-order number, access code, or other private identifier. Confirm that CDN URLs, backups, staging sites, and social previews follow the same decision.

Write captions and text alternatives for different jobs

A caption and alternative text are not interchangeable.

  • Caption: gives every reader project context, such as the stage, material, constraint, or portion of scope shown.
  • Alternative text: communicates the image's purpose in that specific page context to someone who cannot see it.
  • Nearby case-study text: explains complex facts, measurements, sequence, and limitations that should not be packed into an image description.

W3C's alternative-text decision tree asks whether an image contributes meaning, repeats nearby content, performs a function, contains necessary text, or is decorative. Apply that decision image by image.

Examples:

| Use | Suitable approach | | --- | --- | | Informative completed project photo | Briefly describe the visible condition relevant to the paragraph | | Before-and-after pair | Identify each state and convey the meaningful visible difference | | Decorative texture beside a fully explained section | Empty alternative text | | Image used as a link to a case study | Describe the link destination or purpose | | Diagram containing project measurements | Provide the essential information in nearby text |

Do not fill alternative text with city and service keywords. Google recommends useful, contextual alt text and warns against keyword stuffing. Do not identify a person, exact address, or private condition in alt text when the visible page intentionally omits that information.

The website accessibility checklist for Canadian small businesses covers the broader review for galleries, controls, keyboard access, zoom, reflow, and assistive technology.

Deliver useful images without making the page slow

Project photography can become the largest part of a contractor page's download. Prepare derivatives for their actual display sizes rather than sending the camera original to every device.

The implementation should:

  • generate appropriately sized responsive candidates;
  • use a supported modern format with a suitable fallback where required;
  • include intrinsic width and height so the browser can reserve space;
  • avoid stretching or distorting the image;
  • lazy-load below-the-fold images;
  • load the primary above-the-fold image deliberately;
  • preserve enough quality to show the relevant workmanship;
  • expose meaningful images through standard HTML image elements;
  • place the image near its descriptive project text; and
  • test on a slower connection and narrow viewport.

Google's image guidance recommends high-quality, contextually relevant images, descriptive filenames and alternative text, standard HTML image elements, responsive delivery, and speed optimization. web.dev explains that responsive candidates, known dimensions, and selective lazy loading help browsers choose suitable resources and reduce layout movement.

Do not create ten near-identical full-resolution files merely to make a gallery look substantial. Choose the images that prove distinct facts. The Core Web Vitals guide for contractor websites explains how image delivery can affect loading and visual stability.

Put each project on the page that owns its decision

Use one canonical destination for the detailed project story. Then link to it from relevant service or sector pages rather than cloning the same case study into several location variants.

A strong project page can include:

  • a direct project summary;
  • the contractor's verified scope;
  • approved context and broad location;
  • starting condition;
  • decisions or constraints;
  • process stages;
  • completed visible result;
  • supported measurement or customer quotation;
  • limitations and attribution; and
  • a relevant service-page link.

Do not turn a single project into a network of “city case study,” “service case study,” and “best contractor” pages containing the same facts and images. If a project genuinely supports several services, use descriptive internal links and short contextual references that point to the canonical case study.

Avoid publishing the exact address simply to target a neighbourhood query. The useful local fact may be a climate, access, housing-type, permit, material, or scheduling constraint—when verified and appropriate to disclose—not the homeowner's location.

For a website designed to organize service evidence and qualified lead paths, contractor web design in Canada is the commercial owner for this resource.

Approve the composed page, not only the raw photo

Permission to use an image does not approve every caption, headline, crop, call to action, testimonial, or surrounding claim. Review the complete production-like page.

The final approver should see:

  • exact public URL and page title;
  • each selected derivative;
  • crop and sequence;
  • captions and alternative-text decisions;
  • customer and company attribution;
  • before-and-after labels;
  • claims, measurements, dates, and disclaimers;
  • service and location context;
  • calls to action;
  • social-sharing preview; and
  • any structured data that repeats project facts.

Record the approved version or commit so later edits can be compared. A material change to a claim, asset, attribution, location, or promotional channel should trigger a new review.

The website team should also verify that mobile cropping does not remove essential context or expose an area omitted from the desktop crop. Check that lightbox and carousel controls work by keyboard and that the same private original is not accidentally linked as a “download full size” asset.

Prepare correction, expiry, and removal paths

Before publication, decide who receives a concern and who can act. The process should cover:

  • factual correction;
  • attribution correction;
  • accessibility correction;
  • permission expiry;
  • rights dispute;
  • privacy or safety concern;
  • customer removal request;
  • completed contractual removal obligation; and
  • accidental publication of the wrong derivative.

Maintain an index of every live page, social post, proposal template, email asset, CDN object, and structured-data reference using an approved project asset. When a use must stop, changing the main page is only one step.

Do not promise that deletion instantly removes search-engine caches, third-party shares, archives, or files already lawfully distributed unless the business controls that outcome. The response plan should distinguish:

  1. immediate unpublishing from controlled channels;
  2. removal or replacement of controlled files and derivatives;
  3. cache and search-removal requests where appropriate;
  4. notification to downstream teams or partners; and
  5. confirmation of what was completed and what remains outside direct control.

Set a review date even when permission has no stated expiry. Recheck active services, staff or subcontractor attribution, awards, licences, product names, links, and time-sensitive claims. Remove stale evidence when the context can no longer be verified.

Run the publication acceptance checklist

Rights and authorization

  • [ ] Every asset has a known creator and documented rights basis.
  • [ ] Customer or project publication authorization covers the intended material.
  • [ ] Website, social, advertising, proposal, and partner uses are not treated as identical.
  • [ ] Logos, supplier assets, plans, renderings, and third-party work have separate authorization where needed.
  • [ ] The final crop, caption, quotation, attribution, and page context were approved.

Privacy and safety

  • [ ] Identifiable people and personal information were reviewed.
  • [ ] Faces, children, addresses, plates, documents, screens, keys, and security details were checked.
  • [ ] Public derivatives omit unnecessary location and other embedded metadata.
  • [ ] The permission record and high-resolution originals remain private.
  • [ ] The page does not disclose a more precise location than was approved.

Accuracy and claims

  • [ ] The contractor's scope is distinct from work by other parties.
  • [ ] Before and after states, dates, and sequence are verified.
  • [ ] Image edits do not change the commercial impression.
  • [ ] Performance, savings, durability, safety, warranty, and comparative claims have suitable prior support.
  • [ ] Customer words are exact, authorized, and not used as technical proof.
  • [ ] No result, credential, award, licence, project total, or location was inferred.
  • [ ] Captions state useful project context.
  • [ ] Each image has the correct informative, functional, redundant, or decorative alt treatment.
  • [ ] Galleries and lightboxes work with keyboard and assistive technology.
  • [ ] Responsive derivatives, dimensions, loading behaviour, and visual quality pass.
  • [ ] Public filenames and URLs contain no personal or secure identifiers.
  • [ ] The detailed project has one canonical owner rather than cloned location variants.

Operations

  • [ ] Asset IDs connect public derivatives to originals and permissions.
  • [ ] Material edits are recorded.
  • [ ] The approver, approval date, version, and review date are stored.
  • [ ] A named owner can correct or unpublish the page.
  • [ ] Removal can be traced across the site, CDN, social, proposals, and partner uses.
  • [ ] The project-page links, forms, calls to action, analytics, and social preview were tested.

The publication decision

Publish when the team can trace each asset from creator to approved public use, explain what the image proves, separate visible change from unsupported performance, and remove or correct controlled copies when required.

Do not publish when the rights chain is uncertain, consent is assumed, the customer or property is exposed unnecessarily, the contractor's role is overstated, the comparison is manipulated, or the case study needs an invented result to sound worthwhile.

A smaller set of well-documented project examples is stronger than a large gallery of untraceable images. The best case study is not the one with the most dramatic headline. It is the one a customer can understand and the business can still defend after the page has been shared, indexed, and revisited months later.