Planning a confidential project launch.
A confidential launch starts by naming the information that must stay private, who may access it and what may be published. Review the public product and the systems around it. Confidentiality reduces unwanted disclosure; it is not a promise of anonymity or zero traceability.
Use the free worksheetReview a specific disclosure boundary.
Illustrative example: a product may be public, but its commissioning client must not be named in public delivery materials. This does not hide the product or make external provider records anonymous. The review below turns that limited requirement into checks someone can actually perform.
| Surface | Review against the agreed boundary | Record to keep |
|---|---|---|
| Page and social preview | Inspect visible copy, page titles, descriptions and preview images. | The version reviewed, the reviewer and any approved exceptions. |
| Downloadable material | Review text, filenames and document properties before publication. | The exact files approved for the public release. |
| Client-side assets | Check for private configuration and unintended identifying information. | Findings and their resolution, without copying secrets into the record. |
| Studio references | Confirm the absence of client credits, screenshots, project links, results and anonymised case studies. | A no-client-reference rule that also covers private requests from prospects. |
| Provider accounts | Identify what must be supplied to providers and who controls the account. | External requirements and limits that the website review cannot remove. |
Define the confidentiality boundary.
A stealth product, a public website with a private commissioning client and an internal tool with private data have different requirements. State which facts must remain confidential: a person's name, the commercial relationship, unreleased features or a dataset.
Agree who can approve the product's public release and how that approval is recorded. A designer, developer and hosting provider may need different information. This release decision is separate from BRÈCHE's rule against sharing client projects as references.
Review what the finished product publishes.
Inspect visible copy, images, downloadable files, page titles and social previews. A project can omit a client's name on the homepage while still exposing it in an image description or document. Use a specific list of information to check rather than a vague promise to remove all traces.
Public technical assets also deserve review. Client bundles must not contain secrets or private configuration. Source maps, repository visibility and deployment metadata should be considered according to the agreed scope and debugging needs.
Include providers and account ownership.
Domain, hosting, payment and collaboration providers have their own account requirements and data practices. They are part of the delivery context. A studio cannot promise control over every record held by an external service.
Decide who owns accounts and who may access them. Record the information each provider needs and the person responsible for checking it. Crypto payment and the use of an alias do not by themselves make a project anonymous.
Keep client work out of studio references.
BRÈCHE never shares past client projects. That includes names, links, screenshots, credits, testimonials, payment details and results. An anonymised case study or a private reference conversation would still disclose client work, so neither is offered.
A client can choose to publish their own product under their own brand. Review those release materials against the project's requirements. A public launch does not change the studio's no-reference policy.
Carry the requirements into operations.
After launch, someone may upload a new file, change a page title or connect an analytics service. The handover needs to explain which disclosure checks still apply and who can approve changes.
Record the remaining limitations and any responsibilities outside the development scope. A clear boundary is more useful than an absolute privacy claim that the project cannot verify.
The checklist.
- Sensitive information and approved recipients identified.
- Public copy, files and metadata reviewed against that list.
- Account ownership and provider requirements understood.
- No client work appears in studio references, including anonymised cases.
- Private configuration is absent from public assets.
- Ongoing checks for the client's own publications have an owner after handover.
Take it into the project.
Confidential launch review worksheet.
Review the client's own public release while keeping client work out of studio references. This is a planning record, not a guarantee of anonymity.
Download the worksheet (.txt)Plain text, ready to edit. No account or email required.
Preview the worksheet questions
- Information boundary
- Name the facts that must remain private, using neutral references rather than copying sensitive data into this worksheet.
- People and approval
- Identify who may receive each category of information and who approves the client's own public release.
- Public surfaces
- List copy, metadata, social previews, images, document properties, downloads and public repositories. Record reviewer, version and result for each.
- Public build
- Record checks of client assets, configuration exposure and source maps within the agreed scope. List unresolved findings without reproducing secrets.
- Provider responsibilities
- Name domain, hosting, payment and collaboration providers, their account owner and the provider requirements still to verify.
- No client references
- Confirm that no client names, links, screenshots, credits, results or anonymised case studies appear in studio publications or reference materials. BRÈCHE does not share past projects with prospects.
- Launch decision
- List each open disclosure issue, its owner and whether it blocks publication. Record what was actually reviewed.
- After handover
- Assign ongoing checks for new files, metadata, integrations and announcements. Identify who can approve changes to the boundary.