Is it a problem if the agency only offers a zip file?

It is not improper, but you lose commit history, branches, and deployment workflows. That context is what helps the next developer move quickly, so ask up front whether a repository transfer or mirror push is possible.

When is the safest time to receive the source?

Earlier than delivery day. Having commits land in your own organization's repository from the first prototype lowers risk, and at minimum you should clone, build, and run the project before making the final payment.

What happens to the code if I hire SAENRU Studio?

SAENRU Studio hands over the completed work as the full GitHub repository. Websites start at KRW 2.7M over roughly two weeks and web app MVPs start at KRW 8.7M over four to six weeks, with a first prototype in 48 hours. All prices exclude VAT.

How Do You Get Your GitHub Source After a Website Build?

"The site is live, but where is the source code?" A surprising number of clients ask this only after the project ends. They have the domain and an admin login, but the repository still sits inside the agency's account. That gap becomes expensive the moment you change staff or hand maintenance to a different developer. Here is how to take over your GitHub source properly, and what to lock down before you sign.

Why take a repository instead of a zip file?

A zip file is a single snapshot of one moment; a Git repository is the entire history of how the site came to be. Whether the next developer can figure out why the code looks the way it does is what determines your maintenance cost. A repository handover brings all of this with it.

Commit history: you can trace what changed and when, and roll back when something breaks.
Branches, issues, pull requests: unfinished work, known bugs, and shelved features keep their context.
Deployment config: workflow files and deploy scripts must come along, or you cannot ship the next release yourself.
Dependency lock files: files like package-lock.json are what make the same build reproducible months later.
Ownership record: a repository transfer makes your organization the unambiguous owner.

What should the contract say before work starts?

Handover is decided in the contract, not at delivery. If the quote only says "source code provided," a single zip technically satisfies that. Put at least these six items in writing.

Ownership clause: state that on final payment, the copyright or a license including the right to create derivative works passes to you. Make sure "deliverables" explicitly includes source code.
Transfer method: repository transfer, or a mirror push into your organization? If the answer is "zip only," ask why.
Timing: rather than one handover at the end, have commits land in your organization's repository from the first prototype. This dramatically lowers the risk if the engagement ends early.
Environment variables and keys: request a .env.example plus a documented list of required keys, and issue third-party API keys under your own accounts from day one.
Third-party account names: confirm the domain, DNS, hosting, payment, and analytics accounts are registered to your company.
Supporting assets: settle who holds design source files, original images, and any paid font or plugin licenses.

How do you verify the code actually runs?

Receiving code and running code are two different things. The test is simple: on a machine that is not the agency's, clone, install, build, and run. Do this once before the final payment.

Clone the repository and follow the install commands in the README exactly. If there is no setup document, request that first.
Fill in .env.example values and bring the site up locally.
Confirm the build command finishes without errors and check which servers or services the deploy workflow points to.
Look at the commit history. If everything is squashed into one "initial commit," the record of how it was built is gone.
Search the code and history for hardcoded secrets. Anything you find should be revoked and reissued.

Common mistakes at handover

Requesting the source only after the final invoice is paid, leaving no leverage
Receiving an admin login while the repository stays in a developer's personal account
Filing the zip away unopened, then discovering months later that it will not build
Letting the domain stay registered under the agency's name

How does SAENRU handle source ownership?

SAENRU is an open launch stage for AI builders, and the platform principle is simple: the code belongs to the builder. You can list AI-built web and app projects for free, collect votes and feedback, and we encourage open launches on GitHub. The weekly vote winner gets a free main banner slot for one week plus an interview feature. If you have something you built, share it via Launch your project.

If you would rather commission the build, SAENRU Studio runs an AI production pipeline and hands over the entire GitHub repository. Websites start at KRW 2.7M in roughly two weeks, web app MVPs start at KRW 8.7M over four to six weeks, and the first prototype arrives within 48 hours. If you also want AI search visibility designed in, AEO·GEO consulting offers a measured diagnostic report at KRW 190,000 delivered in five business days, and the diagnostic fee is fully credited if you proceed with a build contract. All prices exclude VAT. For reference, the SAENRU site itself is raw HTML with embedded JSON-LD and llms.txt — our own AEO reference build.

Source handover is less a final step than a first condition written into the contract. Confirming the repository address and the transfer method in a single line at the quotation stage keeps your options open, whoever you end up working with.