Ask Who Owns Your Site When the Contract Ends

Introduction

Portfolio, experience, price — the usual due-diligence checklist for picking a web developer misses the two things that actually cause pain later. It's rarely about whether the site looks good on launch day. It's about who controls it a year later, and whether "done" meant the same thing to both sides when the contract was signed.

Who Owns What

Before any work starts, get clear on four things and make sure every one of them is in your name, not the developer's:

• Domain registration. If the developer registered it "to make things easier," that's your business's address sitting in someone else's account.
• Hosting account. If they host it under their own account and the relationship ends badly, your site's uptime is now a bargaining chip.
• Source code repository. You should have access to a real repo (GitHub, GitLab, whatever) — not a promise to "send a zip file at the end."
• CMS and admin access. If content updates require going through the developer instead of logging in yourself, that's a dependency you're signing up for indefinitely.

None of this is paranoia — it's just what "vendor lock-in" looks like for a small business instead of an enterprise one. Ask for all four up front. A developer who hesitates just told you something important.

What "Done" Actually Means

A contract that just says "build us a website" leaves too much room for two different definitions of finished to coexist until launch week, when it's expensive to discover the gap. A contract worth signing specifies the scope in enough detail that you could hand it to a different developer and get roughly the same result, names what happens to anything left unfinished at the deadline, and ties payment milestones to concrete deliverables — not vague phases like "development" or "polish."

Questions That Actually Reveal Something

Skip "tell me about your experience." Ask these instead:

• What happens if my main point of contact leaves the company mid-project?
• Can you show me something you built three years ago that's still live and still being maintained?
• What's your actual process when a client asks for a change mid-project — not the sales answer, the real one?
• Who owns the domain, hosting, and code the day the project wraps?

A confident answer to all four tells you more than a five-year-old portfolio piece. On that note — years in business is a weaker signal than it looks. The same test applies here as hiring an architect: ask what went wrong on a real project and what changed because of it, not how long they've been doing this.

Conclusion

The portfolio tells you what a developer can build. Ownership and a specific contract tell you what happens after they build it — and that's the part that actually determines whether this was a good decision, usually a year after you've stopped thinking about it.

Tyrone Showers