If you pay someone to build you a custom website in 2026 and they don't transfer the GitHub repository to your account, you didn't buy a website. You bought a license to use one. The difference matters more every year as AI tooling matures, hosting becomes commoditised, and the gap between "you own it" and "they let you use it" widens.
This piece argues for owning the GitHub repository of your business website. It covers what that actually means in practice, how the transfer works, why it's the foundation of AI-compatible iteration, and the long-term costs of getting it wrong.
What "Owning the Repo" Means
Owning the GitHub repository of your website means three things, in increasing order of importance.
First, the repository sits in your GitHub organisation. The URL is github.com/your-business/your-site, not github.com/the-agency-you-hired/their-client-projects. Their access to it is granted by you (as a collaborator), not the other way around. You can revoke their access at any time.
Second, you have the admin role. You can add and remove collaborators. You can transfer the repository to a different organisation. You can make it private or public. You can delete it. None of these actions require the original builder's permission.
Third, the repository contains the complete source code of the live website. Every component, every page template, every brand asset, every config file. Cloning the repo and running npm install && npm run dev on a fresh machine reproduces the live site exactly. There are no "secret bits" that live somewhere else.
Why It Matters: Five Concrete Reasons
1. AI Tooling Requires a Real Repo
Claude Code, Cursor, Aider, and every other production-grade AI coding assistant operate on a local git repository. They clone your repo, read the files, plan changes, and ship commits. If your website lives on a SaaS dashboard (Webflow, Wix, Squarespace, WordPress hosted on a managed platform), Claude cannot see it. The AI is locked out.
This isn't a temporary limitation — it's structural. AI tools work with files, branches, diffs, and commits. SaaS website builders don't expose any of those. As AI becomes the dominant way of iterating on websites, having a real repository becomes the precondition for being able to iterate at all. The businesses with their own repos will out-ship the businesses without by an order of magnitude inside three years.
2. Backups Are Free and Forever
A GitHub repository is a distributed backup by default. Every collaborator who clones it has a complete copy. GitHub itself stores every commit indefinitely. If GitHub disappeared tomorrow (it won't), you'd push to GitLab and continue.
Compare this to SaaS-hosted websites. If Wix loses your data, you have what's in their backup (which they may or may not provide). If Webflow goes out of business, you have a static export (no dynamic functionality survives). If Squarespace deprecates a feature your site relies on, you have a broken site and no recourse. The recovery story is brittle.
The repo-based recovery story is bulletproof. Local clone + git push to a new remote + redeploy = back online in 15 minutes.
3. Developer Flexibility
If the developer who built your site disappears tomorrow — moves on, raises rates, goes out of business — you can hire someone else and hand them the repo. They read it, understand it, and pick up where the original developer left off. The transition cost is hours, not months.
Compare to a SaaS-builder site: the new developer has to navigate someone else's account, figure out which "elements" do what, work inside the platform's editor. Often the cleanest move is to rebuild the site somewhere else.
Compare also to bespoke-on-a-hosted-platform (think: custom WordPress on a managed host with proprietary plugins). The new developer has to learn the previous developer's plugin choices, their staging workflow, and any custom theme they wrote. It's possible but slow.
A clean GitHub repo with a README, a CLAUDE.md, and standard tooling (Astro/React/Tailwind/Netlify) is hand-overable to any competent developer in the world in an hour.
4. Hosting Flexibility
Your repo is hosted on Netlify today. You decide tomorrow you want it on Vercel. You change one config file and push. Done. Same code, new host. The same migration takes 5 minutes between Netlify, Vercel, Cloudflare Pages, AWS Amplify, and any other Jamstack host.
Compare to a SaaS website: changing hosts means rebuilding from scratch. You can't take a Wix site to Squarespace. You can't take Webflow to WordPress. The platform IS the hosting.
5. Price Insulation
If GitHub triples their free-tier price next year, you pay GitHub triple. Or you move the repo to GitLab (free) and pay nothing. Either way, the impact on your business is small.
If Squarespace triples their Business plan price next year, your website's operating cost triples. Migrating away is months of work. You're effectively price-trapped.
The repo-based stack puts the hosting price entirely in your control. The SaaS-builder stack puts it entirely in someone else's.
How the Transfer Works
If you're buying a custom website from someone and want the repo transferred, the mechanics are simple. GitHub has a built-in repository transfer feature. The original owner clicks "Transfer ownership" in repo settings, enters your GitHub username or org name, you accept the transfer in your inbox, done. Total time: under five minutes. The full git history transfers with the repo — every commit, every branch, every issue.
Insist on this transfer being part of your contract. Specifically: "Repository ownership transferred to [your GitHub org] within 7 days of final payment, with full admin access and no continued license fees." Get it in writing. The number of horror stories of developers holding code "hostage" after a payment dispute is non-trivial; written contractual transfer terms eliminate the ambiguity.
The Common Objection: "I Won't Know What to Do With It"
The most common pushback on owning your own repo is: "I'm not technical. What am I supposed to do with a GitHub repo?"
Fair question. Three answers.
Answer 1: Nothing, until you want to. Owning the repo doesn't obligate you to interact with it. The site still works the same way. Your developer or AI assistant still does the edits. The repo just exists, ready for you to use when you need to.
Answer 2: Use Claude Code or Cursor to edit it in plain English. The whole point of the AI-coding revolution is that you don't need to be a developer to edit a real codebase anymore. With brand.json and a templated codebase, you can ask Claude "add a new pricing tier called Enterprise at $49,995" and get a working PR. You review the result on the preview URL. You don't need to read the code unless you want to.
Answer 3: Hand it to anyone, anytime. The repo is a portable representation of your website. If you want to switch to a different developer five years from now, you hand them the repo. If you want to bring it in-house, you hand it to your new hire. If you want to put it on the shelf and walk away, you can. The flexibility is the value, even if you never personally touch the code.
Repo Quality Matters
Owning a repository is necessary but not sufficient. A repo full of spaghetti code with no README and obscure conventions is technically owned but practically un-iterable. The repos that deliver on the ownership promise have:
- A README explaining what the project is and how to run it.
- A CLAUDE.md (or equivalent) describing conventions for AI assistants.
- A brand.json or equivalent canonical brand-context file.
- Sensible folder structure (src/components, src/pages, src/styles).
- A standard build pipeline (npm scripts, no obscure tooling).
- Environment variables documented (.env.example with placeholders).
- Deploy config visible (netlify.toml or vercel.json).
When you buy a custom website with the repo included, audit these. If the README is missing or the conventions are absent, ask for them as part of the build. A handed-over repo without documentation is a half-handed-over repo.
Frequently Asked Questions
Does GitHub cost money?
For private repositories with up to a few collaborators, GitHub Free works. Most small business websites stay on the free tier indefinitely. GitHub Team is $4 USD/user/month if you need more collaborators or advanced features. Compared to a $30-$100/month SaaS website builder, GitHub is essentially free.
What if I use GitLab or Bitbucket instead?
All three work fine. The principle is the same: own the repository in a place you control. GitHub has the largest ecosystem (more developers know it, more AI tools integrate with it), which is why it's the default recommendation. GitLab and Bitbucket are valid alternatives.
What about non-tech-savvy owners?
Owning the repo doesn't require interacting with it. Think of it like owning your domain name — you registered it, you control it, but you've probably never opened the DNS dashboard. The repo can sit in your account the same way. When you need it, it's there. When you don't, it's not in your way.
Can the developer who built it still work on it after transfer?
Yes. They become a collaborator on your repo, with whatever permission level you grant. You can give them admin access, write access, or read-only. You can change or revoke their access at any time. Their ability to work is preserved; their leverage over you is eliminated.
What if I want to make the repo public?
You can. Public repos are free on GitHub. Some businesses prefer their site's source to be open for SEO transparency and developer trust. Others prefer private. It's your call once you own the repo.
What about credentials and secrets?
Real secrets (Stripe keys, database URLs, API tokens) never go in the repo. They live in environment variables on the host (Netlify, Vercel) and never get committed. The repo can be public or private without security risk if secrets are managed properly. Audit your repo to confirm no .env file with real values was accidentally committed; rotate any keys that ever touched a commit.
The Bottom Line
Owning the GitHub repository of your business website is the single biggest leverage point in the custom-vs-SaaS-vs-managed-platform decision. It enables AI tooling, eliminates lock-in, makes hiring flexible, makes hosting flexible, and protects you from price changes you don't control. It costs nothing. The only friction is making sure your contract specifies the transfer at the end of the project. If you take one thing from this piece: when you next pay someone to build you a website, get the repo transferred. Everything else flows from there.