Share client work only when you have permission for the exact material, audience, channel, and duration, and when the released package has been checked for confidential data.
Share client work only when you have permission for the exact material, audience, channel, and duration, and when the released package has been checked for confidential data, credentials, personal information, licensed assets, misleading claims, and unclear contribution. A public website does not automatically make its source files, analytics, admin screens, messages, or internal decisions available for reuse.
Build a separate sharing package rather than publishing production exports directly. Record permission, minimize the evidence to what supports your claim, redact through removal and replacement, attribute other people’s work, describe your own contribution precisely, and have someone inspect the final files from a clean location. When permission is uncertain, use a fictional or independently created demonstration instead.
Start with one professional claim: for example, you designed the responsive content hierarchy, implemented a validated form, created an icon system, or improved a documented workflow. Name the decision, constraint, artifact, and verification evidence that supports it. Do not share an entire client environment when two sanitized images and a short explanation prove the point.
Separate evidence from promotion. A screenshot can show layout, while a decision record explains why it changed. A test result can show behavior, while an analytics result requires authorized data and a defensible method. Avoid revenue, conversion, ranking, traffic, or satisfaction claims that you cannot substantiate and disclose responsibly.
Review confidentiality, intellectual-property, publicity, trademark, data-processing, subcontracting, and portfolio clauses in the relevant agreement. Do not interpret this article as legal advice. When wording is unclear or risk is material, ask the client and seek qualified local advice before sharing.
Request permission in writing with the project, exact artifacts, intended description, audience, channels, publication date, duration, attribution, links, and removal process. A client may permit a private interview sample but not a public social post, or permit a final page but not an admin screen. Preserve the approved scope without attaching unnecessary confidential material.
List every candidate file: screenshots, recordings, code, designs, documents, emails, data, metrics, test results, logos, fonts, photographs, icons, and third-party interfaces. For each, record owner, source, license, sensitivity, permission status, required redaction, and whether it is necessary for the claim.
Reject unnecessary items early. Raw database exports, support tickets, customer messages, production logs, credential files, invoices, contracts, internal roadmaps, and private repositories rarely belong in a work sample. Minimization reduces both risk and the amount of redaction you must trust.
Look for names, email addresses, phone numbers, account identifiers, addresses, photographs, device details, payment information, analytics identifiers, unpublished prices, internal URLs, infrastructure details, security controls, access patterns, and business plans. Consider information visible in browser tabs, notifications, menus, file paths, status bars, and image metadata.
OWASP logging guidance identifies secrets, tokens, personal data, payment data, and other sensitive values as information that should be excluded or protected. Apply the same care to portfolio evidence. A value can remain sensitive even when it appears in a test log or background panel rather than the main subject.
Search for passwords, API keys, tokens, private keys, recovery codes, connection strings, cookies, session identifiers, webhook URLs, environment values, and embedded credentials. Revoke or rotate any secret that was exposed to an unauthorized file or person. A black rectangle over a screenshot does not make the underlying repository or shared design file safe.
GitHub warns that removing sensitive data from repository history can be disruptive and that exposed credentials should be revoked or rotated. Do not publish a cleaned latest commit while the secret remains in history, releases, forks, caches, artifacts, or issue attachments. Follow the platform’s official incident process and involve the authorized owner.
Prefer deleting unnecessary layers, pages, rows, metadata, and attachments. Crop the capture to the relevant feature. When the interface needs context, rebuild it with synthetic names, values, images, and records in a safe demonstration environment. Keep a mapping so every replacement is intentional and no production value survives.
Do not rely on blur when the original remains recoverable in an editable file, PDF layer, video frame, thumbnail, or revision history. Flatten only after verifying that the source package is safe, and preserve the private original according to the client’s retention rules. Redaction is a content process, not merely a visual effect.
Prepare the browser or device before capture: close unrelated tabs, disable notifications, use a clean profile, clear autofill suggestions, hide bookmarks, and select synthetic records. Check the address bar, page source indicators, status area, developer tools, console, network panel, and downloads before and after capture.
For video, inspect the complete timeline, transitions, loading states, hover details, tooltips, error messages, and audio. A private value may appear for one frame. Export the final format, play it from a clean location, and check generated thumbnails. Do not record real customer actions merely because the screen is already public to staff.
Create a small authorized sample or public-safe branch containing only the code required to explain the contribution. Remove environment files, customer-specific configuration, internal domains, infrastructure names, private dependencies, licensed packages, and comments that expose operations. Preserve license notices and authorship where required.
State whether the example is adapted, simplified, or reconstructed. Do not present tutorial starter code, open-source components, a colleague’s module, or generated code as entirely your own. If production code cannot be shared, use a diagram, pseudocode, test description, or fictional implementation that demonstrates the reasoning without copying protected material.
Check logos, photography, illustrations, fonts, icons, templates, mockups, datasets, and interface libraries separately. Client permission may not override a third-party license. Record the creator, source, license, permitted use, modification status, and required notice. Replace assets when public portfolio use is not allowed.
Creative Commons recommends useful attribution that includes title, creator, source, and license when available. Follow the actual license and platform terms rather than assuming one format fits every asset. Do not add a Creative Commons label to material the client or another creator has not licensed that way.
Write what you were responsible for, what others supplied, what constraints were fixed, which decisions you made, and what was verified. Use first-person claims only for your work. Name collaboration without disclosing private team details. If you improved an existing system, explain the starting boundary rather than implying a complete original build.
Keep outcomes proportional to evidence. Designed and tested a responsive form is different from transformed the client’s business. If analytics are authorized, state period, baseline, sample limits, confounding changes, and your contribution. Otherwise focus on requirements, decisions, defects corrected, accessibility checks, test coverage, and maintainable handoff.
Create a dedicated folder with the approved description, sanitized assets, attribution record, permission record reference, review checklist, publication channels, expiry or review date, and removal contact. Do not place the client’s full approval email or contract inside a public package; store permission evidence securely and reference it.
Use descriptive filenames and export formats appropriate to the channel. Strip unnecessary metadata and confirm dimensions, color, readability, and crop. Keep the public package independent from production drives so a future upload cannot accidentally include neighboring private files.
Ask a reviewer who did not prepare the files to inspect every artifact at full size and in its final context. Provide a checklist for secrets, personal data, client identifiers, internal systems, metadata, licenses, attribution, contribution claims, unsupported outcomes, visible text, and links. Review the final exported files, not only the design canvas.
Open archives and repository links using an account with no private access. Test whether hidden layers, history, comments, downloads, or source maps reveal excluded material. Hash the approved package when practical. Any later edit creates a new version that needs the affected checks again.
Use only the named channels and approved copy. Verify captions, alternative text, links, tags, previews, and thumbnails before making the item public. Do not tag client staff, use a trademark in advertising, or invite public access to a private preview unless permission explicitly supports it.
For a broader portfolio structure, the technology portfolio evidence guide can help organize scope, decisions, tests, and finish criteria. A Web Design course or Graphic Design course can strengthen presentation skills, but neither supplies client permission.
Maintain a contact and removal process. If the client withdraws permission within the agreed terms, a license changes, a vulnerability appears, or sensitive data is discovered, unpublish affected files, preserve incident evidence securely, rotate exposed secrets, and notify the authorized parties. Do not wait for search engines or caches to disappear before containing the source.
Review time-limited permission and old claims on schedule. A project that was safe to show at launch may later reveal retired systems, employee details, outdated branding, or unsupported results. Archive or replace the example when you can no longer verify its permission, accuracy, and relevance.
Public availability does not automatically grant permission to reuse screenshots, logos, source files, analytics, private interfaces, or project details. Check the agreement and request scope-specific permission.
Not by itself. Remove unnecessary content, rebuild with synthetic data, inspect editable layers and metadata, and verify the exported file. Rotate any secret that was exposed.
Create a fictional or independently built demonstration that proves the same skill without copying protected assets, code, data, branding, or confidential decisions.
Explore RisingEdge courses designed to help students learn real skills, build projects, and prepare for career opportunities.
Freelance capacity planning happens before you promise a delivery date. List current commitments, estimate the new work by deliverable, identify client and third-party.
Get the latest guides, insights, and course updates.
No spam. Unsubscribe anytime.
A freelance website proposal should define the work clearly enough for the client and freelancer to make the same decision. State the business outcome, deliverables.
