A surprising number of website contracts never answer a basic question: after launch, who can actually change something on the page. If the honest answer is "only the agency, for an hourly rate," you've bought a website without the practical use of it, and every typo fix, price update or new testimonial becomes a support ticket. Whether you can edit your website after an agency builds it should be settled before the contract is signed, not discovered the first time a headline needs to change.
This isn't a technical question so much as a commercial one. Two agencies can hand over code that looks identical in a repository and leave you in completely different positions six months later, depending on what "handover" actually meant.
What "you own everything" should actually mean
It means the content lives in a model you can open and edit without a developer standing between you and the page. That means an actual admin panel or content editor, credentials issued in your name, and a site that keeps working after the agency stops answering emails. A PDF of brand guidelines or a verbal promise to make changes upon request is not ownership.
Ownership that only holds while the original team is reachable isn't ownership. It's a support contract with a website attached, and the difference only becomes visible at the worst possible moment, usually when a price is wrong on a live page and nobody at the company can fix it before the weekend.
The three questions that settle it before you sign
Ask these of any web agency before a contract is signed, and get the answers in writing rather than a verbal reassurance:
- Can I log in and change text or images myself, today, without asking? If the answer involves "we'll set that up later" or "usually," that's a no.
- Whose name is the domain and hosting registered under? If it's the agency's account rather than yours, you don't own the site, whatever the contract says about the code.
- What happens to the content model if I stop paying a retainer? A platform that stops rendering correctly the day a subscription lapses was never really handed over in the first place.
Any vendor who answers all three cleanly, in one sentence each, has actually done this before. Hesitation on question two is the most common tell, because a domain sitting in an agency's account is the cheapest way to keep a client from leaving, and it rarely gets mentioned until someone tries.
Where the platform changes the answer
The platform decides how far "you can edit it" actually reaches. A marketing site with frequent copy changes suits WordPress or Webflow, both built around a client editing routinely without touching code. Real e-commerce suits Shopify, where a client manages products and inventory as a matter of course rather than an exception. Genuinely custom logic or an app-like interface can justify custom React, but that route trades some day-to-day editability for capability a template simply can't offer.
None of the three platforms is the universally right answer. The right one is whichever matches how often you'll actually be inside the site making changes, not the one an agency defaults to because it's the stack they know best.
What a proper handover includes
A proper handover starts with the build itself, on an editable content model from day one, and it ends with a walkthrough rather than a document dump. Routine copy and image changes shouldn't require touching code or filing a request with anyone. A handover without an explanation of what is safe to change is just a login. The first broken layout sends the client straight back to the agency's inbox anyway, which quietly defeats the entire point.
This is also where knowing when a rebuild is actually the right call starts to matter. A site nobody can edit without help often gets replaced early, not because the design failed, but because the ownership did, and a full rebuild is an expensive way to solve a handover problem that should have been fixed the first time.
A worked example: what changes without a call, and what still needs one
On a properly handed-over site, the following should never require contacting the agency: a new staff photo, an updated price, a seasonal banner, a fixed typo, a new blog post drafted in-house, or a testimonial swapped out for a fresher one. These are content changes, and content belongs to whoever runs the business, not to whoever wrote the original code.
Server-level changes, new features, structural redesigns and anything touching site performance or security are a different category, and reasonably still call for someone who builds these for a living. Migrating hosting, adding a new integration, or restructuring how a section of the site works are engineering decisions with real ways to go wrong, and treating them the same as a copy edit is its own kind of mistake.
Where the agency still comes back in, honestly
Drawing that line clearly, in both directions, is what separates a healthy client relationship from a dependent one. The failure mode isn't only agencies that lock clients out. It's also agencies that quietly let every request, however small, route back through them, because an open content model with no walkthrough gets used exactly as rarely as one that was never built.
Being straightforward about that boundary instead of blurring it, so genuinely every change funnels back through the agency's queue, is what's actually worth checking references on before signing anything.
Before you sign anything
Ask the three questions above, in writing, before any contract for a website build goes out for signature. The answers say more about what you're actually buying than the proposal ever will, and they cost nothing to ask.
