How to share enough access for a useful review.

Before Sharing Anything

• Send a scope request with the app URL, stack, launch goal, and what you are worried about.
• Tell us whether the app handles payments, personal data, health data, regulated data, or admin functions.
• Do not send passwords, API keys, tokens, private keys, PHI, cardholder data, customer records, or production credentials.
• Ask for a mutual NDA before sharing sensitive repository, infrastructure, or business context.

Preferred: Read-Only Repository Access

If your code is in GitHub, GitLab, or Bitbucket, the simplest path is read-only repository access. This lets us inspect source, dependencies, configuration, CI, deployment files, and project structure without changing anything.

• Invite the agreed VibeChex reviewer account or organization with read-only access.
• Share only the repositories in scope for the review.
• Include related infrastructure repositories only if deployment or cloud configuration is in scope.
• Remove or rotate secrets before granting access if secrets have been committed.

GitHub Steps

• Open the repository in GitHub.
• Go to Settings, then Collaborators or Collaborators and teams.
• Invite the reviewer account we provide.
• Choose Read access when GitHub asks for a role.
• Send us the repository link after access is granted.

If You Cannot Grant Repo Access

A source archive can work, especially for early prototypes, but it is usually slower to review than a clean repository. A zip file often lacks history, dependency context, deployment assumptions, and clear entrypoints.

• Create a fresh export after removing secrets and generated build artifacts.
• Include a short README with how the app runs, what database it expects, and where it is deployed.
• Include lockfiles, package manifests, Dockerfiles, CI files, Terraform, Kubernetes, or deployment config if those are part of the system.
• Do not include database dumps, customer uploads, production logs, `.env` files, private keys, or credentials.

Customer-Owned Workspaces

For some work, a customer-owned Codespace, cloud workstation, self-hosted runner, or temporary VM is better than handing over code directly. You keep the environment, revoke access when finished, and control what tools can run.

• Use a temporary workspace with no production secrets.
• Grant only the access needed for the agreed review.
• Use test credentials, seeded demo data, and disposable resources when dynamic checks are required.
• Revoke access when the engagement ends.

Deployed Websites and APIs

Do not assume we can actively scan a live system. Dynamic testing only runs against targets you authorize in writing.

• Share the public URL and whether production traffic is live.
• Tell us what we may test and what is off limits.
• Provide test accounts only when needed, never real customer accounts.
• Tell us about rate limits, payment flows, background jobs, and third-party systems that could be affected.

Customer-Run Tooling

We are designing customer-run tooling, but it is not a public offering today. For now, do not download or run any VibeChex binary unless we have explicitly scoped that workflow with you.

The current default is read-only access, customer-owned workspace access, or a controlled source archive after scope is confirmed.

Start Here

Not sure which path fits? Request scope with a short description of the app. We will tell you what access is needed before asking for anything sensitive.