The GitHub organisation holding your code may not be yours
Many small studios build under a personal GitHub account rather than yours. When the relationship ends, you may discover you never actually owned the repository.
When a small studio builds your website or application, the code has to live somewhere while it is written. The easiest place is a GitHub account the studio already has open, a personal account, or an organisation the studio owns and reuses for every client. Nobody thinks twice about this at the start of a project. Everyone is focused on design, build and launch.
The trouble shows up later. If you want to change developers, move hosting, or simply look at the history of your own product, you need access to the repository. If that repository sits inside the studio's personal account, you are asking a third party for permission to see your own work. Most of the time this goes smoothly. Sometimes it does not, and the delay lands at the worst possible moment, mid migration, mid dispute, or mid renewal of a licence that is about to lapse.
Ask where the repository actually lives
Before work begins, ask a direct question: which GitHub organisation will hold this code, and who is the owner of that organisation. The answer should be an organisation you control, not a personal account belonging to a developer, and not a shared organisation the studio uses across many clients. Your name, or your company's name, should sit at the top of that organisation as the owner, with the studio added as a collaborator with the access it needs to do the work.
This is a small thing to set up and an expensive thing to fix later. Moving a repository between accounts is mechanically simple. Working out who has the right to authorise that move, months after the relationship has gone quiet, is not.
A repository you cannot move is not really yours, whatever the invoice says.
What a fixed price should already include
A fixed price project should include the administrative groundwork, not just the finished product. That means the organisation is created in your name before the first commit, deployment keys and domain records are documented, and access is handed over cleanly at the end of the engagement, not requested back from a studio that has moved on to other work.
You do not need to understand GitHub permissions in depth to ask for this. You only need to ask the question early, in writing, and confirm the answer before the project starts. A studio that already works this way will have the answer ready. One that has never thought about it is telling you something useful about how the rest of the engagement will go.