Back
Legal

Privacy policy

Last updated 2026-06-24.

This policy is written for the actual SellCodebase workflow: GitHub identity, selected-repository GitHub App access, estimate previews, codebase submission review, encrypted archive storage, analytics, email, optional Slack alerts, payout setup, and account deletion.

1. Scope

SellCodebase (“we,” “us,” or “our”) operates sellcodebase.com and the related repository appraisal, submission, review, payout, and support services (the “Service”). This Privacy Policy explains what we collect, why we use it, who can receive it, and what choices you have.

Your use of the Service is also governed by our Terms of Service. Do not submit source code, files, secrets, personal data, regulated data, or third-party material that you are not authorized to disclose and license.

2. Account and GitHub data

When you sign in or connect GitHub, we collect and store:

  • GitHub identity data from OAuth, including GitHub account ID, login/name, email address, avatar URL, provider account ID, provider name, OAuth scopes, token expiration fields, and encrypted OAuth access, refresh, or ID token values when GitHub provides them.
  • SellCodebase account data, including user ID, name, email, profile image, role or admin flags, ban fields if applicable, timestamps, authentication sessions, session tokens, session expiration, IP address, user agent, verification records, and database-backed rate-limit records.
  • First-party authentication cookies and a short-lived session cookie cache used by Better Auth to keep you signed in and protect account routes.
  • GitHub App installation records, including installation ID, GitHub account login, GitHub account ID, account type, repository selection mode, granted permissions, and timestamps.

GitHub OAuth is used for identity. Private repository access uses the SellCodebase GitHub App, not a broad OAuth repo scope. GitHub App installation tokens are generated server-side when needed and are not stored as permanent database fields.

3. Repository browsing and estimate previews

If you type or paste a repository, the Service may parse the repo input and check GitHub for public/private visibility. Signed-in repository screens list the private repositories you selected in the GitHub App, including repo name, visibility, language, size, pushed date, installation summary, and whether a repo already has an active submission.

Estimate previews are intentionally not the persistence boundary for repo appraisal data. A private estimate may read GitHub language bytes through your selected-repo GitHub App access and return an estimated line count, payout preview, quality score, and language breakdown. That route does not create a submission, store the repo estimate, or save the repo URL, score, estimate, or language breakdown in SellCodebase database rows. We store those appraisal details when you submit the repository for review.

4. Submission and review data

When you submit a repository for review, we collect and store:

  • Repository metadata such as full name, GitHub URL, default branch, submitted commit SHA, GitHub App installation ID, repository size, visibility, active-submission status, and submission timestamps.
  • Appraisal and processing results such as estimated and final line counts, internal line-count output, quality scores, quality grades, score reasoning, commit-timing evidence, review-signal packets, estimated payout, final payout, processing errors, and status history.
  • Intake answers and flags covering your relationship to the repo, rights and license status, copied or generated code, AI tool usage, model families, project status, usage, revenue range, tests, CI, docs, deployment targets, dataset context, private dependencies, secret handling, personal or regulated data risk, excluded paths, desired offer, deal shape, payout preference, and free-form notes.
  • Contact and profile details you provide, such as contact email, phone number, preferred contact method, timezone, preferred deal shape, payout method, PayPal email, Wise email, or bank-transfer account reference. The current in-app bank flow stores an account reference only; routing details are collected later if needed after qualification.
  • Admin review fields such as status, rejection reason, admin notes, reviewed timestamp, paid timestamp, submission events, archive state, and archive deletion or failure state.

5. Source code access and archives

When a repository is submitted, our ingestion job creates a short-lived GitHub App installation token, downloads the submitted commit tarball to temporary server storage, extracts it, runs the internal TypeScript line counter, scores the codebase, collects review signals, encrypts the tarball locally, uploads only the encrypted archive to Cloudflare R2, and deletes the temporary working files.

Submitted archives use AES-256-GCM with a random per-archive data key. The data key is encrypted before it is stored in Postgres. The database stores archive metadata such as storage provider, bucket, object key, plaintext and ciphertext SHA-256 hashes, byte sizes, encryption algorithm, encrypted data key, IV, auth tag, archive state, stored timestamp, requested-deletion timestamp, and deleted timestamp.

Admin code review can also read selected text files live from GitHub using a short-lived GitHub App token. The admin browser is limited to a bounded file list and blocks large or binary files from inline display. It does not expose GitHub tokens, R2 keys, or archive encryption material to reviewers in the browser.

6. Analytics, logs, email, and Slack

In production, we use Vercel Web Analytics for page-view and product-event measurement. Before page views are sent, the app redacts repo appraisal paths and the repo, redirect, and error query parameters.

Product events are separate from page-view URLs. Submission, cancellation, status-change, GitHub sign-in, bulk-action, and payout events can include operational properties such as repo full name, owner, repo name, submitted URL, default branch, visibility, repo size, estimated lines, payout estimates, score, grade, submission ID, old and new status, coarse failure reason, final payout, whether a rejection reason exists, method selected for payout, field count, and a short hash of your user ID. Payout events do not send the actual payout account details.

We may keep operational logs for debugging, security, availability, and abuse prevention. Logs can include request metadata, user IDs, installation IDs, repo names, status values, error messages, and failure reasons. If email is configured, Resend receives the email address, subject, and message content needed to send seller submission, qualification, rejection, and payment-status emails, as well as internal new-submission review notifications. If Slack alerts are configured, Slack can receive a new-submission alert with repo name, seller email, estimated lines, score, and estimated payout.

7. How we use data

We use collected data to:

  • authenticate users, maintain sessions, secure accounts, enforce same-origin and fresh-session checks, prevent abuse, and operate rate limits;
  • connect selected GitHub App installations, list selected repositories, verify repository access, and refresh stale installation records;
  • provide estimate previews, create submissions, process code snapshots, count lines, score codebases, prepare review evidence, and manage submission status;
  • perform manual review, confirm seller authority, evaluate transaction fit, communicate with sellers, prepare diligence, and coordinate potential buyer outreach under the Terms of Service;
  • send operational emails, internal alerts, support responses, security notices, and payout-status updates;
  • store payout preferences, support payment operations, handle tax or compliance follow-up, investigate fraud or rights issues, and enforce legal agreements;
  • measure product usage, diagnose failures, improve flows, and verify that privacy-sensitive paths are being redacted where intended.

8. Who receives data

We do not sell personal information, and we do not run advertising trackers. We share data only as needed for the Service, review, transaction, safety, support, or legal purposes described here and in the Terms of Service.

  • GitHub receives OAuth and GitHub App requests needed for sign-in, selected-repo listing, estimates, repository metadata, tarball download, commit timing, and admin code review.
  • Neon stores account, session, GitHub App installation, profile, payout preference, submission, review, event, and archive metadata in Postgres.
  • Cloudflare R2 stores encrypted submitted-codebase archive objects and object metadata.
  • Vercel hosts the app and receives production analytics events and hosting/runtime metadata.
  • Resend receives transactional email data when email sending is configured.
  • Slack receives internal new-submission alert data if a Slack webhook is configured.
  • Payment, tax, banking, legal, accounting, compliance, or support providers may receive the information required to qualify, complete, report, reverse, or investigate a payout or transaction.
  • Employees, contractors, advisors, affiliates, and potential buyers may receive submission metadata, review summaries, samples, excerpts, diligence materials, or code access where needed for review, buyer outreach, transaction diligence, enforcement, or support under the Terms of Service.
  • Authorities, courts, platforms, rights holders, or other parties may receive information when required by law or when reasonably needed to protect rights, safety, security, users, SellCodebase, or the public.

9. Snapshot deletion and retention

Estimate previews do not create submission records or stored code archives. Once a repository is submitted, the submission record and encrypted archive remain while the submission is pending, under review, qualified, or paid unless a deletion rule applies.

If you cancel a pending or under-review submission, the app marks the submission cancelled, deletes the R2 archive object if one exists, clears archive encryption material from the database, and leaves a non-code submission record in your dashboard. If the R2 delete fails, cancellation fails closed and records a retryable archive deletion error instead of pretending the code is gone.

If an admin rejects a submission, the app marks the archive for deletion and attempts to delete the R2 archive object. If deletion succeeds, archive encryption material is cleared and the record is marked deleted. If deletion fails, the rejection remains recorded and the archive state is marked as failed so an admin can follow up.

Account deletion deletes your profile, payout details, submissions, review events, GitHub App installation records, auth sessions, and stored archive objects before removing your account database row. If archive deletion fails, account deletion fails closed so we do not lose the database pointer needed to retry deletion. Legal rights granted for paid submissions may survive account deletion under the Terms of Service, even when the current account-deletion workflow removes stored archive objects. Some records may remain in backups, provider logs, email systems, payment/tax records, legal files, or security records for the time required by operational, legal, tax, accounting, dispute, fraud-prevention, or backup needs.

10. Security

We use selected-repository GitHub App access, short-lived GitHub App installation tokens, encrypted OAuth token fields, CSRF and origin checks, secure cookies in production, signed GitHub App setup state, database-backed rate limits, encrypted submitted-codebase archives, per-archive data keys, encrypted archive data keys, server-side archive credentials, and admin-only review routes.

No system is perfectly secure. We cannot guarantee that a repository or account will never be accessed, disclosed, altered, or destroyed. You should remove secrets, credentials, customer data, personal data, regulated data, and anything else you are not allowed to disclose before submitting a repository.

11. Cookies and tracking choices

We use first-party cookies for authentication, session state, and account security. We use Vercel Web Analytics in production for traffic and product-event measurement. We do not use third-party advertising cookies or behavioral ad trackers.

You can control cookies through your browser settings, but blocking authentication cookies may prevent sign-in, repository review, and account deletion from working.

12. Your choices and rights

You can:

  • disconnect or modify the SellCodebase GitHub App from GitHub's installed-app settings;
  • revoke GitHub OAuth authorization from your GitHub account settings;
  • cancel a pending or under-review submission from SellCodebase where the app allows cancellation;
  • update payout preferences and contact details in account settings;
  • delete your account from settings after confirming with a fresh session and the required DELETE confirmation;
  • email us to request access, correction, export, deletion, or help with privacy rights that apply in your location.

We may need to verify your identity before acting on a request. We may decline, limit, or delay a request when allowed or required by law, including for paid transaction rights, security, fraud prevention, dispute handling, tax, accounting, legal compliance, backups, or records we need to provide the Service you requested.

13. Children

The Service is not intended for children. You may use the Service only if you meet the eligibility requirements in the Terms of Service. We do not knowingly collect personal information from children through the Service.

14. Changes

We may update this Privacy Policy as the Service changes. If we make material changes, we will update the date above and provide any additional notice required by law or appropriate for the change. We will not silently expand how we use sensitive submission data in a way that conflicts with this policy without an appropriate notice or consent path.

15. Contact

For privacy requests or questions, email hello@sellcodebase.com.