Most people find out what their web agreement actually says at the worst possible moment: when they want to leave. The site is built, the invoices are paid, and then it turns out the domain sits in someone else's account, or the code isn't theirs, or ending the retainer means starting over.
None of that is exotic. It's ordinary industry practice, and it survives because the questions that would expose it are awkward to ask and easy to forget. So here they are, written down. All seven can be answered in a single email, and how someone responds tells you more than their portfolio does.
1. Who owns the code once it's paid for?
When the final invoice is paid, do I own the design, the content and the source code written for my business?
A good answer: Yes, on full payment — in writing, before you start. Expect sensible carve-outs: third-party tools, themes and apps keep their own licences, and most developers keep their own reusable libraries. That's normal and reasonable.
Red flag: Anything that grants you a "licence to use" rather than ownership. A licence can be revoked. Ownership can't.
2. Whose name is the domain registered in?
This is the one that causes the most damage, because the domain is the only part nobody can rebuild for you. Lose the code and you can have it written again. Lose the domain and you lose your email, your search history and every business card you've ever handed out.
Which registrar account will my domain be registered in, and whose name is on the registration?
A good answer: Registered in your name, in an account you can access, with the developer added for technical access if they need it. Being told plainly who holds what is the point — not who does the day-to-day work on it.
Red flag: Vagueness. "We handle all that for you" is not an answer to a question about legal ownership.
3. What actually happens if I leave?
If I stop working with you in a year, what do I walk away with, how long does it take, and what does it cost?
A good answer: A clear list — code, repository, domain, hosting — moved into accounts in your name, with help during the handover, and no exit fee.
Red flag: An exit fee, a "migration charge", or a shrug. Anyone who has thought about this will have an answer ready, because they've done it before.
4. Is the price published, or does it depend on me?
There's a reason so many agencies won't quote before a call. A price that only appears after they've learned your industry, your turnover and your postcode is a price calibrated to you rather than to the work.
What does a project like mine usually cost, roughly, before we talk?
A good answer: A range, immediately, with an explanation of what moves you up or down within it. Nobody can quote exactly without knowing the scope — but everyone can give you a band.
Red flag: Total refusal to indicate a number until they've qualified your budget.
5. Who is actually going to build it?
Will the person I'm speaking to now be the person doing the work?
A good answer: A straight answer either way. Agencies with teams are perfectly good — but you should know whether you're meeting the senior and getting the junior, and who you'll speak to when something breaks.
Red flag: The pitch is led by someone you never hear from again.
6. What's included after launch?
Launch day is when the relationship changes. Find out beforehand whether support is part of the build or the beginning of a new invoice.
What happens in the first month after go-live, and what does it cost?
A good answer: A defined period of post-launch support included in the build price, covering fixes and small updates, with anything beyond that quoted separately.
Red flag: Support that only exists as a monthly plan you have to sign up to on the day you launch.
7. How do changes get priced?
After launch, how much is a small change, and how do I know before I approve it?
A good answer: A per-change rate or a retainer with a stated scope, and a quote before any larger work starts.
Red flag: Open-ended hourly billing with no estimate. That's how maintenance bills quietly become the largest line item in the relationship.
The pattern worth noticing
Every one of these questions is really the same question: what do I still control when this goes wrong? Good answers are specific, come quickly, and are already written down somewhere. Bad answers are reassuring in tone and vague in content.
You don't need the answers to match what I'd say. Plenty of good developers work differently to me. What matters is that someone can answer at all without having to go and check — because if they haven't thought about it by the time you're asking, they certainly won't have by the time you're leaving.