GitHub for a business that is not a software company

The GitHub organisation a company ends up with is usually created by whoever was building at the time, which is why it is usually owned by an individual. That one fact decides more about the business's software than any technical choice inside the repository: whether a new developer can be added on Monday, whether the history survives the person who made it, and whether the company can leave a supplier without asking permission. A repository is worth treating as a business record — the dated place where a requirement, the decision it produced and the reason for that decision sit together — and not as a folder somebody uploads to.

What is a repository for, when you do not write code?

It carries more than source: the specification, the database schema and its migrations, the deployment configuration, the names of the credentials it needs, the notes on which external service does what, and a history of every change with a date and a reason attached.

A zip of the current code tells the next developer what the system is; the repository tells them what happened to it. The history tells them why invoice numbering skips a range, why one report is computed at night, and which of two similar tables is actually in use.

Why does the account owner matter more than the code?

Because ownership of the organisation is what lets the company act. An organisation has owners, and owners add people, remove people, change billing and recover access. A repository inside a developer's personal account has one owner: that person, their mailbox, and whichever phone their second factor lived on.

The failure is not dramatic. A contract ends, a freelancer changes number, a studio closes. The code is still there, on a service nobody at the company can administer, and the only route back is a message to somebody who may not answer. Two reachable owners, both with a second factor, is the minimum — the OWASP authentication guidance is written for application logins, and the reasoning holds for the account that holds the company's source: one credential on one device is one point of failure.

Billing, the recovery address and the notification address must also be the company's; all three default to whoever signed up.

How do issues and pull requests become an audit trail?

An issue is a request with a date, an author and an acceptance condition. A pull request is the change that answers it, with the diff and the review attached, and a merge that closes the issue. Read together, they answer the question that arrives in year two: who asked, when it was agreed, what changed, and whether anybody checked it before it went live.

A WhatsApp group contains the same conversation and none of the structure: no state, no owner, no closing, and no way to search it once the phone that held it is gone. Teams that run the project in chat and the code in GitHub end up with two histories, one of which cannot be produced when a client disputes an invoice.

What does a private repository entitle the client to?

Private means unpublished, not unowned, and the confusion runs both ways: a client assumes private means inaccessible to them, a supplier assumes it means theirs.

What the client should hold is short: membership of the organisation from the first week, read access to every repository the project touches, the right to add another developer without asking, and the ability to clone the full history rather than the current files. The licence question is separate and belongs in the contract — a repository can be readable while the code inside it is licensed for use only.

What makes a repository readable by the next person?

A README that says what the system is, how to run it locally, which environment variables it needs and where their values come from, how it is deployed, and who to ask. Written for somebody who has never seen it, and tested by having them follow it.

A commit message that says why. fix: duplicate invoice numbers when two tills save at once is a record. update is a shrug, and a hundred of them make the history worthless.

A place for decisions with consequences. One docs/decisions.md, an entry per decision with the date and the alternative that was rejected, costs an hour and prevents the argument that begins with "we discussed this".

What does a working setup look like?

Piece	What it holds	What it replaces
The organisation account	Owners, billing, membership	A developer's personal login
Issues	What was asked, by whom, when	A chat thread
Pull requests	What changed and who reviewed it	"It is done"
README and commit messages	How to run it, and why it changed	A handover call nobody recorded

How do you set it up in an afternoon?

1. Create the organisation with an address on the company's domain, not the founder's personal mailbox.
2. Register two owners, both with a second factor, and put billing on the company card.
3. Move every repository into the organisation and give the builder write access rather than ownership.
4. Write the README before the second developer exists, then have somebody who has never run the project follow it.
5. Decide where requests live and where decisions live, and say so in the README.
6. State the commit-message rule once and check it monthly; it decays quietly.
7. At handover, add the incoming team, remove the outgoing one, and rotate every secret the configuration mentions.

Where this goes wrong

• The repository lives in a personal account. The company pays for the work and cannot add a single person to it.
• Issues used as a suggestion box. Requests opened, never closed, no label for accepted or rejected, so nobody reads the tracker.
• Secrets in the repository. A key in a config file is in the history forever, and rotating it is the only repair.
• The README describes a laptop. Steps that work on the original developer's machine, with a database nobody else has.
• A zip at handover. No history, no branches, and no way to tell which files are running in production.

What this advice leaves out

Nothing here describes what any plan includes; that belongs to the vendor's page and it changes. It also leaves out continuous integration beyond the note that its configuration belongs in the repository, and the legal question of who holds copyright — a contract matter, not a repository setting. The mechanics above assume a company that commissions software and keeps it.

We work inside client organisations, build in accounts the client owns, and take no commission from any platform vendor.

We build the repository as a company asset, in the company's name, with a README the next developer can follow.