Your agency should not own your website

Some agencies don’t sell websites. They sell dependence with a nice homepage attached.

The pitch sounds tidy. They build the site or app, they host it, they renew the domain, they handle the updates. You pay a monthly fee and life feels simpler because one supplier owns all the annoying parts.

Then the relationship changes. The invoices keep landing, and one day you ask a basic question. Can we have the code, the server access, the domain login and the deployment details?

Suddenly the friendly arrangement gets very specific. The code lives in their private repository. The hosting account is theirs. The domain sits under their login. Only their team can deploy a change. The app has your name on it, but operationally you’re renting space in someone else’s system.

That’s where vendor lock-in starts, and parts of the web industry have got far too comfortable selling it to you as convenience.

Managed service is not the problem

There’s nothing wrong with paying someone to host, maintain and support a website or app. Loads of businesses should do exactly that. Hosting is fiddly. Security updates matter. Backups need checking, domains need renewing, and SSL certificates, DNS records, analytics, uptime monitoring and deployment pipelines all quietly waste time when nobody owns them properly.

A good managed service takes that burden off you without taking custody away from you.

The problem starts when the supplier makes themselves the only practical way into the system. They’ll call it support, or managed hosting, or say it’s safer for the client. Sometimes it genuinely is. Sometimes they just don’t want you able to leave cleanly.

If leaving means losing the code, the server, the domain or the data, the monthly fee isn’t support any more. It’s rent on a project you already paid for.

The polished cage

The worst lock-in looks great at the start.

The site is well designed. The proposal is neat. The monthly fee feels manageable. The supplier promises to take care of everything, and to a busy owner that sounds like relief.

The detail is where it bites. Who owns the source code repository? Which account holds the hosting? Who controls DNS? Can another developer deploy a change? Can the database be exported? Are the backups accessible? Are the admin accounts in your name? Is anything documented, or does one person at the agency hold the whole thing in their head? Those answers matter more than the screenshot in the proposal.

Some agencies like the trap, because it turns a one-off project into permanent dependence. You pay for the build, then you pay rent on access to the thing you funded. Every small change becomes a ticket. Every urgent fix waits on the supplier’s availability. Every future migration kicks off with awkward emails and missing credentials. When the supplier benefits every time you can’t act without them, the friction isn’t an accident.

Domain custody is not admin trivia

Domain ownership is one of the most neglected parts of a website project, and it shouldn’t be.

If the agency registered the domain in its own account, you’re exposed. The relationship sours, a bill gets missed, the agency closes, or a staff member walks out the door, and your site and email can be put at risk by something as ordinary as a renewal slipping through.

The domain belongs in your name, or in an account you control. The agency can help manage it, act as a technical contact, handle renewals by agreement. But you need clear access and visibility on the billing. Your domain is a business asset, not a favour from the web company.

Server access is a security issue

Some suppliers wheel out security as the reason they won’t give you access. Fair enough, occasionally. Production systems shouldn’t be a free-for-all.

But keeping the client in the dark isn’t security. Real security looks like least-privilege access, named accounts, audit trails, recovery paths, documented credentials, backup procedures and clear owner control.

If a supplier won’t tell you where your app is hosted, who has access, how backups work, or how another qualified person could take over, they’re not protecting you. They’re protecting their choke point.

You don’t need every staff member logging into production. You do need a credible way to regain control during an incident, a dispute, a migration, or the supplier going under.

Code ownership must be usable

Contracts often say the client owns the work. Great. So where’s the usable source code?

For a website, usable ownership covers the theme, templates, custom plugins, static site source, build scripts, design files, content model, deployment instructions and repository access. For an app, it covers the application code, database schema, environment requirements, API documentation, deployment process and any custom infrastructure configuration.

A login to an admin dashboard is not the same as the system.

There are honest exceptions. If the supplier is selling access to its own product or proprietary platform, they should say so before you sign. You’re buying a hosted product, not a custom asset you can take anywhere, and that’s fine when everyone understands the trade. The dishonest version is letting you believe you’re buying a custom website or app while quietly keeping the parts that would make it portable.

What a clean handover should include

A serious build should leave you with enough control to carry on without the original supplier.

You don’t have to run all of it yourself. You just need options. Keep the supplier. Bring in another developer. Move the hosting. Audit the system. Respond if the supplier vanishes.

At a minimum, ask for:

• Source code in a repository you can access.
• Documentation for build, deployment and maintenance.
• Hosting access or ownership through your own cloud account.
• Domain registrar access and DNS control.
• Database export and backup access.
• Admin access for the CMS, analytics, email, forms and third-party tools.
• A list of paid services, licences and renewal dates.
• A secure process for handing over secrets and API keys.
• A plain explanation of what can’t be transferred, and why.

If a supplier acts wounded by that list, take note. A good agency might push back on how access is granted, because security matters. A bad one pushes back on the idea that you should have control at all.

How Rangefront handles it

When Rangefront Labs builds a website, app or business system, you shouldn’t need us forever.

We can host and support the work when that’s the right arrangement. We can manage deployments, monitor systems, maintain the code and help with renewals. You still keep the code you paid for, the accounts that matter, the architecture notes, and a way to move the work if you ever need to.

For custom software, that means repository access, documented deployment, clear ownership of hosting accounts and a handover path. For websites, it means the content, source, domain, DNS, analytics and hosting setup aren’t hidden behind our login. For integrations, it means you know which systems are connected, which keys exist, and what happens when something fails.

Some of that is ethics. Some of it is self-interest. A client who’s free to leave and chooses to stay is a better relationship than one held together by missing passwords.

Ask before you sign

Before you commit to a website, app or hosted system, ask the uncomfortable questions up front.

Who owns the code? Who owns the domain? Where is the site hosted? Can we get into the server or cloud account? Can another developer take over? Can we export the data? What happens if we stop paying the support fee? Which parts are proprietary? What documentation do we get?

How they answer tells you most of what you need to know.

Some agencies build excellent software and run excellent managed hosting. Others build a nice front end over a locked door. You usually find out which one you hired the day you ask who holds the keys.

Rangefront Labs builds websites and content platforms, custom software and systems integrations with ownership clear from the start. If you ever need to take the code, the hosting details or the documentation elsewhere, you should be able to do that without a hostage negotiation.