I have a problem with registering domains. When I have an idea for a Web site, software project, organization, or sometimes just a pun or joke, I’ll go on a domain registrar site and see what related domains are available. I’ll brainstorm a bit in the search screen to try some different options for names or top-level domains, and if I find something in my price range, I’ll buy it, even if I’m not going to use the domain right away.
This leaves me with a portfolio of unused domains that are like reminders of unfulfilled dreams. Ah yes, the Web site for the Frito pie restaurant I never made. Oh, right, I was going to start a social network for people in the Plateau de Montreal. Each year, as the renewal deadlines come up, I have to decide if I’m going to give up this little dream, or give myself another year to get started.
The fact is, I just don’t have the time or the energy to make as many social networks or Web sites or joke URLs as I’d like. I have a full-time job, a family, and existing responsibilities at the Social Web Foundation, CoSocial.ca, and the Social Web Community Group. I can’t spend money on dreams I’m not fulfilling, just because I’m afraid to let them go.
So, I’m trying to change my habits and come up with a new strategy for using domains. It’s aspirational for now, but I hope I can use it to reduce some of my personal expenses on new domains and domain renewals. I’m sharing it here with you partially in hope that it can be useful, and partially to hold myself to the strategy.
Domain strategy- Register a short, personal domain name. I know, this probably doesn’t seem like a great first step, but bear with me! This domain is going to be the basis for a long term presence. Also, it’s a chance to get it out of your system, and put those domain registration superskils to use one last time. Use something that represents yourself, as a person, not a company or your personal consulting firm or design agency or whatever. I use https://evanp.me/ , which I registered a while ago specifically for this purpose.
- Assign the root domain to a content-management system. For me, that’s this WordPress blog. Other people might want to use Drupal or Jekyll or a wiki or some other publishing system. You can even use plain old HTML, if that’s how you want to fly. The important thing is that you need to be able to create new pages on a path you like — preferably of arbitrary depth, but at least with user-defined pathnames.
- When you want to register a domain for a new static website, make a page on the root domain instead. OK, now we’re into the part where we’re actually saving money. When you get an idea for a Web site, and you start searching for domain names, stop doing that. Instead, create a page on your personal CMS. So, for example, when I wanted to register a new domain for the ActivityPub book I wrote, I instead created a page at https://evanp.me/activitypub-book/ . This has two benefits. First, it keeps me from registering a domain for a project I’m not even going to start. Second, it keeps me from burning up all my creative energy on domain-buying, and gets me to use whatever momentum I have to write a first draft of the page I need, and possibly either share it out on my blog or on my social network presence(s). Note that using a short domain puts more emphasis on the page’s path than on the domain.
- When you want to register a domain for a new Web service, use a subdomain of your personal domain name instead. There are a lot of Web applications and services that need specific server-side code and databases and can’t be run as a page on a WordPress site — like a Mastodon server, a MediaWiki site, or a NodeJS application I made up. A lot of people will never need to do this; as a software developer, this is something I do all the time. When I need to make a server that can’t run within WordPress, instead of registering a new domain, I create a domain name for my service that is a subdomain of my personal domain. So, if I want to set up a Mastodon server (I don’t, right now) I’d make a subdomain at social.evanp.me and use it for the server. The benefit here is that I have a domain name to start off with, and also I don’t worry about starting to use it until I actually have a server available. One particular trick that has worked well for me is to use a wildcard DNS record that points to a Kubernetes cluster ingress. I can use the ingress to route between services, without having to create or update the subdomains. It saves a couple of steps in this process.
- If a project needs to become independent, register a domain and move to it. This is the safety valve that lets me feel OK about not using the “right” domain for a project from the outset. Of course, “needs to become independent” is a hard to specify objectively, but some good rules of thumb are whether there are enough collaborators that I don’t feel comfortable giving them an account on my personal blog, or if the people who use the service or page ask why it’s still linked to my personal domain. At the point when a domain is actually needed, I can go register it, move the service or content to use it, and then use URL redirection to move traffic from my personal site or service to an independent one.
Having this as an option lets me worry a lot less when starting a new project. There are also so many top-level domains (TLDs) available today that I don’t feel like I have to grab a domain just so it doesn’t get squatted by others. It’s OK to use one of the less popular TLDs if the project is becoming its own thing.
So, that’s it. Have a personal domain, put a CMS behind it, use that for publishing static pages, use subdomains of it for standalone services, and register new domains only when you need to. I think this kind of strategy is inherent in the idea of having “your own domain”, and a lot of people follow it to a greater or lesser degree, but I wanted to spell it out fully to make it clear to myself how I would deal with different circumstances.
Let me know if you have other tips for reducing your domain registration spending by committing to a good personal domain.