A web developer holding a domain hostage is the most common form of domain theft in the cases we handle, and it is the one owners are least prepared for. There is no hacker, no phishing email and no overseas registrar. There is a vendor the organization hired and trusted, who already had the access needed to move the domain, and who then refused to give it back without more money. Make a Home Foundation, a Connecticut nonprofit that serves veterans and families rebuilding their lives, went through exactly that. This case study explains what happened, what we did, and what every nonprofit and small business should put in place so that a developer dispute never becomes a domain dispute. It is one of our domain recovery case studies.
The organization and its domains
Make a Home Foundation is a nonprofit based in Middlebury, Connecticut. It furnishes homes for veterans, survivors of domestic violence and people leaving homelessness. The foundation was established in 2010, and that same year it registered two domain names, makeahomefoundation.org and mahfct.org. For at least ten years its website ran on those names.
For a small nonprofit, the domain is not a technical detail. It is the address donors type and the address printed on grant applications, brochures and email signatures. Losing it means losing the public face of the organization and much of its ability to raise money.
What happened during the website redesign
The foundation hired a web developer to build a new website. To do that work, the developer was given access to the account at the registrar (the company with which the domains were registered). During the project, the developer used that access to transfer both domains into his own control. He then held them and demanded additional payment before he would return them.
From the foundation’s point of view, nothing had been stolen in any obvious way. The developer had been given the login. No security alert was triggered, because the person who moved the domains was the person the foundation had invited into the account. The registration record now showed someone other than the foundation, and the organization that had used the names for a decade was asked to pay to get them back.
Why this is the most common theft we see
Account takeovers and support-desk fraud get the headlines, but in our recovery files the developer or vendor who holds the domain is the situation we encounter most often. The reason is structural. Small organizations rarely have an IT department, so the person who builds the website is also the person who registers the domain, configures the DNS and manages renewals. Over time, the line between access to the domain and ownership of the domain disappears. When the relationship sours, over a billing dispute, a missed deadline or a change of vendor, the developer discovers that the domain is a bargaining chip.
Nonprofits are especially exposed. Volunteers, board members and vendors change from year to year, and the person who originally registered the domain may be long gone. Our page on domain name ownership explains why the name in the registrant field, not the name on the invoice, is what registrars recognize. We have written separately about recovering a domain name held for ransom by a developer.
What we did
We started with the evidence. We documented the original 2010 registrations and the foundation’s continuous use of both domains for more than ten years. That file is the foundation of any recovery, because every remedy, from a demand letter to a UDRP (Uniform Domain-Name Dispute-Resolution Policy) complaint to a lawsuit, turns on proving who the domain belongs to.
Bill then spoke with the developer several times to ask for the return of the domains. Those conversations did not resolve the matter; the developer would not return them. In parallel we prepared the UDRP route, which allows a party with rights in a name to ask a panel to order a domain transferred when it was registered and is being used in bad faith.
A UDRP complaint carries filing fees and, usually, legal fees, and a small charity serving veterans does not have that money sitting in a budget line. So we helped the foundation launch a GoFundMe campaign to cover the legal and UDRP filing costs. Bill published the foundation’s story on April 2, 2026, in his article on the veterans nonprofit whose domains were held hostage, and helped with media outreach so that supporters and the wider domain industry understood what had happened.
Where the case stands
The matter is not resolved. As of November 2026, the web developer still controls makeahomefoundation.org, despite the documented registration history, the repeated requests for its return and the public attention the foundation’s story received. We continue to work with the foundation on the dispute route, and we will update this case study when the domain is back in the foundation’s hands.
The open status of this case is itself the lesson. A vendor who holds a domain does not need to break any system to keep it, and even with clear evidence of ownership, getting a domain back from someone who refuses to cooperate can take months and real money. The controls described below cost almost nothing by comparison.
Lessons for nonprofits and small businesses
The foundation did nothing unusual. It hired a developer and gave him the access he asked for. That is precisely why this situation repeats, and why a few simple controls prevent most of it.
Give developers DNS access, not registrar ownership
A developer building a website needs to point the domain at a server, which requires DNS access (the ability to edit the records that tell the internet where the site and email live). A developer almost never needs the ability to transfer the domain or change the registrant. Keep the registrar account in the organization’s name, under an organization-controlled email address, and grant developers access only to DNS, either through a delegated user role or by hosting DNS separately.
Never let a vendor register the domain in its own account
If a developer registers a new domain for you, it must be registered in your organization’s name and account from day one. A domain sitting in a vendor’s account is a domain the vendor controls, whatever the invoice says.
Put ownership in writing
Every web development agreement should state that all domain names are the client’s property, that the developer will not transfer or change their registration, and that credentials will be returned at the end of the engagement. A written agreement does not stop a determined bad actor, but it turns a disagreement into a clear breach and strengthens every later remedy.
Know that holding a domain for ransom has legal consequences
Courts have addressed this situation directly. In DSPT International v. Nahum (9th Cir. 2010), the Ninth Circuit affirmed a $152,000 jury verdict against a former employee who registered his employer’s domain and withheld it to extract disputed commissions, holding that a person can be liable under the Anticybersquatting Consumer Protection Act for holding a domain name for ransom with a bad faith intent to profit, according to the Ninth Circuit’s opinion in DSPT International, Inc. v. Nahum.
Monitor the registration
Monitoring that alerts on changes to the registrant, the registrar and the nameservers tells you the day a domain moves, rather than the day the website goes down. For a nonprofit with rotating staff, that alert may be the only warning anyone receives.
How DNAccess helps when a developer holds your domain
A web developer holding a domain hostage is a recovery problem with a clear evidentiary path: prove the registration history, prove the use, and apply the remedy that fits. Our stolen domain name recovery service documents ownership, handles communication with the current holder, and prepares UDRP or litigation support when negotiation fails. If a developer, vendor or former employee is holding your domain, contact DNAccess and send us what you have.