The 3 Questions Every Lawyer Should Ask Their Web Developer

The 3 Questions Every Lawyer Should Ask Their Web Developer

Most lawyers hire a web developer the same way they might hire a contractor to paint their office: get a quote, agree on a price, hope for the best. The problem is that web development agreements have structural risks that a painting job does not. A painter does not get to take your walls with them when the contract ends. Some web developers effectively do.

You do not need to become a technical expert to protect yourself. You just need to ask three questions before any work begins, and know what the right answers sound like.

Question 1: Who Owns the Website When We Are Done?

This is the most important question, and the answer needs to be unambiguous: you do. The domain, the hosting account, the codebase, and all of the content should be registered in your name and transferable to any other developer without permission or penalty.

The reason this question matters so much is that a significant portion of the legal marketing industry is built around the opposite arrangement. Large agencies like Scorpion build law firm websites on proprietary platforms. When you leave, the site does not come with you. You lose the design, the content, the SEO history built up over months or years, everything. The switching cost is not incidental, it is the business model. As long as starting over is painful enough, you stay.

The same risk exists with smaller developers who register your domain in their own account, host your site under their own hosting plan, or build on a platform you do not have independent access to. This is sometimes done out of convenience rather than bad intent, but the practical result is the same: someone else controls infrastructure your practice depends on.

The right answer to this question is not just "yes, you own it." The right answer is a developer who sets up your domain registrar account in your name, your hosting account in your name, and hands you the login credentials. If a developer resists this or offers vague reassurances instead of a concrete setup, that is a meaningful red flag.

It is also worth asking specifically about the platform. A site built on WordPress, with you as the account holder for both the hosting and the domain, is fully portable. Any competent WordPress developer in the world can pick it up and continue from where the last one left off. A site built on a proprietary system, or one where the developer has kept all the access credentials, is not.

Question 2: What Happens if I Want to Stop Working with You?

A good developer should be able to answer this without hesitation: you stop paying, the work stops, and your site keeps running exactly as it was because everything is in your name. No exit fees, no transition penalties, no held hostage period while credentials are transferred.

The reason to ask this explicitly, rather than assuming, is that exit terms vary enormously and are rarely volunteered upfront. Some arrangements involve long-term contracts with early termination clauses. Some involve monthly retainers where the developer retains leverage because access credentials were never fully handed over. Some involve platforms where data export is technically possible but practically painful.

Ask the developer to walk you through the offboarding process as if you were ending the relationship today. What would you receive? What would transfer? What would you need to set up yourself? A confident, clear answer is a good sign. Evasion or a pivot to "but why would you want to leave?" is not.

This question also surfaces contract terms you should read carefully before signing. If there is a contract, look for auto-renewal clauses, notice periods required to cancel, and any language about platform ownership or data retention. These are the terms that matter most and the ones most likely to be buried.

Question 3: How Will You Handle Ongoing Maintenance and Security?

A website is not a finished product. It is a piece of software running on a server, and like all software it requires updates, monitoring, and occasional intervention when something breaks or a vulnerability is discovered. The question of how maintenance is handled is really several questions at once: who does it, how often, what does it cost, and what happens when something goes wrong outside of business hours.

For WordPress sites specifically, core updates, theme updates, and plugin updates need to happen on a regular basis. Outdated plugins are the most common entry point for the kind of automated attacks that compromise law firm websites, exposing client data and triggering the notification obligations that come with a breach. A developer who built your site two years ago and has not touched it since is not the same as one who is actively monitoring and maintaining it.

The practical questions to ask are: Is ongoing maintenance included in the project price, or is it a separate engagement? What is the response time if the site goes down or is compromised? Is there a backup strategy, and how recent are the backups? Who do you email at 10pm on a Friday when the contact form stops working the night before a trial?

There is no single right answer to how maintenance should be structured. A flat monthly retainer, an hourly arrangement, or a bundled service all have legitimate uses depending on the size and complexity of the site. What matters is that there is a clear answer and that the developer has thought about it. Vague answers about "we handle it as needed" with no further detail usually mean the maintenance plan is you noticing problems and filing support tickets.

If you want a concrete sense of what a maintenance retainer should realistically cost and what it should cover, my $200/month webmaster retainer breakdown covers that in detail.

Why These Three Questions

There are plenty of other things worth knowing about a web developer: their experience with law firm sites, their familiarity with ABA advertising rules, their design sensibility, their turnaround time. Those all matter. But they are secondary to these three because the answers to these questions determine the structural terms of the relationship, not just the quality of the work.

A developer who does excellent work but retains ownership of your domain has put you in a difficult position regardless of how good the site looks. A developer who builds a beautiful site but has no maintenance plan leaves you exposed in ways that will eventually cost more than the original project. And a developer who is vague about what happens when you want to leave is telling you something important about how they think about the relationship.

Ask these questions before shaking on it, not after the site is live. The answers are much easier to act on when you still have leverage.

If you want straightforward answers to all three from someone who has been doing this for over 20 years, I am easy to reach.