Skip to content

Learn / Ownership

Export the code. Keep control.

A product you cannot download, read and redeploy is a product you are renting. This is the short path to owning yours properly.

Why source ownership matters

Owning the source means you can change hosts, hire a developer, audit what runs, and recover from a mistake. It is the difference between a product and a demo that happens to be live.

Repository setup

  • Create the repository under an account or organisation you control.
  • Push the full export as the first commit so you have a clean baseline.
  • Add a .gitignore that excludes dependencies, build output and local env files.
  • Protect the main branch once more than one person is committing.

Public versus private

Private is the safe default for anything commercial. Public is reasonable for teaching material or open source — but only after you have confirmed there is nothing sensitive in the history, not just the latest commit.

Keys and secret safety

If a key has ever been committed, rotate it. Deleting the line does not remove it from the repository history.
  • Keep secrets in environment variables on the host, never in the code.
  • Commit an .env.example with names only, no values.
  • Use separate keys for staging and production.
  • Never call a paid or privileged API directly from the browser.

README and documentation

  • What the product does, in two sentences.
  • How to install, run and build it locally.
  • Which environment variables are required.
  • How a release reaches production.

Deploying from a repository

Connect your host to the repository so that every deploy is traceable to a commit. Manual uploads make it impossible to answer the only question that matters during an incident: what exactly is running right now?

Reviewing generated code

  • Read anything that touches authentication, payments or personal data.
  • Check that server-only logic is not running in the browser.
  • Look for unused dependencies and dead files before launch.
  • Confirm error states exist, not just happy paths.

Version-control basics

  • Small commits with messages that describe the change.
  • A branch per piece of work, merged once it is tested.
  • Tag releases so you can roll back to a known-good version.