Lean Domain Search: Two Weeks After the HackerNews Launch

Two weeks ago I launched Lean Domain Search, a new domain search tool, on HackerNews.

If you’re not familiar with it, Lean Domain Search pairs your search term with 1,000+ other keywords commonly found in domain names and instantly shows you which of the generated domain names are still available. It makes finding a great domain name for your website really, really easy.

I’ve launched four other apps on HackerNews (Domain PigeonHNTrendsPreceden, and jMockups/LeanDesigns) and Lean Domain Search was by far the one that was met with the most enthusiasm. And rightfully so — finding a great domain name is a problem that everyone with a web presence faces and until now — even with the existing tools — it’s been very hard to find a good one without spending a lot of time or money on it.

Traffic Overview

Here’s what week 1 looked like (click to view full size):

This is the typical pattern in each of the startups I’ve launched:

Launch day you get a huge boost of traffic from the early adopters checking out the new-hot-thing and then over the next few weeks it stabilizes at a much lower number. Consider: not everyone who visited that first day needed a domain name that day. What’s important is not how many visitors you get when you launch, it’s how many come back. Lean Domain Search saw 8,350 unique visitors the first day thanks to sitting on the HN frontpage for almost 20 hours. Two weeks later and with no major additional press coverage, that number of daily uniques has stabilized at around 400.

Traffic though is not a good indicator of quality — so how’s it actually doing?

Metrics Overview

One important indicator of how useful the tool is is the average number of searches per visitor. If you find the tool useful, you’re more likely to make additional searches so tracking the averages searches per user is a pretty good indicator of quality. In this case, that number has steadily risen since the launch:

And this makes sense — launch day (Jan 16) had a lot of folks just checking it out so you’d expect the number of searches to be lower. As the ooh-shiny-thing traffic fades off, the people who are left are the ones who are actually using the tool for its intended purpose. Currently, the average number of searches per user is hovering at around 4.

The average number of available results has also steadily risen:

Again, I think this is simply due to the nature of the people who are using it — the longer you stick around, the more likely you are to search for less-common and obscure words which on average will return more available domain names. Currently, the average number of available domains returned per search is a little over 600 and I expect that number to go up a lot over next few weeks (more on that in a moment).

One thing I’ve spent a lot of time on since the launch is improving the quality and speed of the results. Here’s a graph showing the impact of my speed optimizations:

On launch day, the average search took 4.39 seconds (227 domains/second). Yesterday, the average search tool 2.98 seconds (335 domains/second), a 47% increase in speed (the duration distribution is actually bimodal — if you search for a phrase that has been searched for before, a cache will kick in and it will take fractions of a second; if you search for a new phrase, it takes a few seconds to perform the lookup; it averages out around 3s).

By the way, all of these metrics were tracked by Mixpanel. If you run a JavaScript heavy application, you absolutely should be using it to track your app’s analytics.

Finally, one important qualitative indicator is the number of positive things folks are saying about Lean Domain Search like “This is exactly what I need. I have been having difficulty looking for viable domain names that contain good keywords and that I can use as a business name as well. Great help.” and more colorfully “Holy balls that comes back with some quick results.” You can read the other testimonials here. :)

Design Improvements

Here’s the design on launch day and now (click to enlarge):

The overall design hasn’t change much, but there are a few notable exceptions.

  • Added filtering and sorting options (starts with search term, ends with search term, sort by length or alphabetical)
  • Added a News section where I can post significant updates for visitors
  • Added a Synonyms section which lists synonyms of your search term if they exist
  • Added Moniker and BlueHost to the list of registrars
  • Darkened the shade of green used for available search results
  • Changed the registration box from a fixed position to a draggable dialog box so users can move it out of the way
  • The registered search results are now hidden by default
  • The “Add to favorites” icon (which used to be a plus sign you’d see when hovering over a domain) is now in the registration options box — I did this because opening the registration options box now automatically triggers a “double-check” feature which confirms the availability of the domain name you clicked on and I don’t want users adding domains to their favorites that are actually registered
  • Added a testimonials link on the footer and removed the UserVoice suggestions link (no one was using it)

The Future (Viva la Revolución!)

With the major kinks worked out, it’s time to start looking forward.

Starting today (Monday, 30 Jan), I will add 100 new domains per week to the search results. From launch day until today, there have been 1,000 results when you search for a given term. Today, there are 1,100. Nine weeks from now, there will be 2,000 search results. And i’ll continue doing this as long as the quality of the results stays high and the servers can handle it.

Bottom line: it’s now easier than ever to find a great available domain name. If you’re launching a new blog, a startup, or any other endeavor that requires a new domain name, you should never have to pay a domain-squatter again.

Give Lean Domain Search a shot and let me know how to make it better.

Matt (@mhmazur)

Remembering AOL’s FDO91 Programming Language

Back in 1999 I cofounded AOL-Files.com, which eventually grew into the largest AOL hacking site of its kind.

One of the primary methods we used to discover exploits in the AOL software was by writing our own script’s using AOL’s Form Definition Order (FDO) programming language. From the AOL-Files FAQs on FDO:

FDO stands for Form Definition Operator. AOL communicates using this programming language. For example, after clicking any icon or button in AOL, FDO code is sent by the AOL system and interpreted by your AOL to create a window. So, the FDO language is the language used to describe forms on the AOL client. This site has focus on learning how to program in FDO and provides a surfeit of examples and tutorials for those who want to learn.

When BMB, Rob, and I started AOL-Files, FDO was all but unknown outside of the AOL development teams.

We did not have any official documentation, but through lots of experimentation we were able to figure out how FDO worked and eventually how to use it to discover holes in the AOL software and service.

Here, for example, are three tutorials I wrote back in the day as an introduction to FDO91 (the version of FDO in use at the time):

To give you an idea of how much we sought after an official manual, I wrote this in the first lesson:

FDO tutorials are unheard of. I have heard rumors that very few people at AOL have the FDO91 Manual. I will pay money for any professionally written, extensive, and full tutorial. Name your price.

A little dramatic maybe, but we really did want the official manuals. Rather than reverse engineer it through experimentation, an official manual would tell us exactly what did what and with that information we could discover exploits at a much faster rate than ever before. Alas, we never got ahold of one and had to make due with figuring it through trial and error.

Why mention all this now? A friend recently pointed me to this photo on Flikr by Joe Loong:

We have:

  • Building an Online Service
  • New Building User’s Guide
  • Editorial Plan
  • FDO91 Manual – Volume 1
  • FDO91 Manual – Volume 2
  • Information Provider’s Guide
  • Bringing Information Online Using Rainman (more info on Rainman here)
  • FDO88 Manual

Wow. Only 12 years too late :)

How to Add Terminal Aliases in Mac OS X Lion

One quick productivity hack is to add command line aliases to your Terminal in Mac OS X.

For example, I prefer typing c instead of clear to clear the terminal and I usually add all sorts of shortcuts for cd’ing into directories that I use often.

Here’s how to do it:

1) Navigate to your home directory:

cd ~

2) Open up .bash_profile using vi:

vi .bash_profile

3) Add an alias (press i):

alias c="clear"

4) Save the file (press Escape, type :wq, and hit Enter)

5) Restart Terminal

If you followed this example, you should now be able to just type c and Enter in Terminal to get the same affect as typing clear.

For more information, this post gives some additional examples of aliases you can add.

How to Change Your Default Terminal Prompt in Mac OS X

By default, when you open up a new Terminal window in Mac OS X the command prompt displays a relatively long name:

I prefer to shorten this to a simple dollar sign ($) in order to free up space.

To change your default command line prompt, follow these instructions:

1) Navigate to your home directory:

cd ~

2) Create a file called .bash_profile

vi .bash_profile

3) Add the following line (press i)

export PS1="$ "

4) Save the file (press Escape, type :wq and hit Enter)

5) Restart Terminal

You should now see something like this:

There are other ways you can configure the command prompt (for example, showing the current time), but I prefer to keep it simple.

How to Change Your Default Screenshot Location on Mac OS X Lion

I’m just getting around to setting up my new Macbook Pro and figured I’d document my experiences in case it helps anyone else.

In order to write tutorials I need to take screenshots and by default Mac’s save screenshots to the Desktop, which I don’t like because  the Desktop tends to get cluttered very quickly.

Instead, I prefer to keep them in a separate folder reserved only for screenshots.

To change the default screenshot location, follow these instructions:

1) Create a folder called Screenshots in your Pictures folder (or wherever):

2) Open up Terminal and enter the following (one line):

defaults write com.apple.screencapture location /Users/yourlogin/Pictures/Screenshots

(Replacing yourlogin with your login name.)

3) Restart your computer for the changes to take effect

After you restart, new screenshots will be automatically saved to the Screenshots folder instead of the Desktop:

Hat tip to Macworld for the original instructions.

New Twitter Name: @mhmazur

Hey everyone, I just changed my Twitter name from @leandesigns to @mhmazur. If you were following @leandesigns, it should have automatically updated for you.

I originally set up the @leandesigns account after I renamed jMockups to Lean Designs, but never really found the right balance between using it for marketing and using it for personal use. I’m not much of a Twitterer (?), but saying Hi to friends from a company’s Twitter account seemed awkward. I probably should have used it more to engage with folks looking for a web design tool, but that always seemed too spammy (which is probably wrong).

Anyway, I think I’ll use it more now that it’s just a personal account. Feel free to say hi @mhmazur.

How to Switch Your Cedar Heroku App from Webrick to Thin

Received an en email today from Cody K on my use of Webrick in production for Lean Domain Search:

Hey Matt,

Lean Domain Search is really neat – thanks for making it available.

Just wanted to let you know that it’s a really bad idea to run Ruby web apps with Webrick in production – you should be using something like nginx and either Unicorn or Passenger. Those are battle-hardened and production-ready, whereas Webrick’s sole purpose is for development environments, and, as such, is not heavily tested (if at all) for security issues and whatnot.

Just a friendly heads up. :) Thanks again.

Heroku’s Rails 3 docs are also pretty clear on this and I remember reading it during my initial upgrade, but never got around to actually doing it.

Thin is a recommended app server over Webrick (the default for rails).

Switching to Thin is pretty easy:

1. Add gem 'thin' to your Gemfile:

I added it to the production group because I want to keep using Webrick in development for now.

2. Make sure that you run bundle install to update your Gemfile otherwise you’ll receive a warning like this when you push to Heroku:

You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
You have added to the Gemfile:
* thin

3. Add a Procfile to your root directory to instruct Heroku to use Thin instead of Webrick:

4. Commit and push your updated app to Heroku.

If all went well, you should see something like this in your logs:

2012-01-18T12:44:33+00:00 app[web.1]: >> Using rack adapter
2012-01-18T12:44:33+00:00 app[web.1]: >> Thin web server (v1.3.1 codename Triple Espresso)
2012-01-18T12:44:33+00:00 app[web.1]: >> Listening on, CTRL+C to stop
2012-01-18T12:44:33+00:00 app[web.1]: >> Maximum connections set to 1024
2012-01-18T12:44:34+00:00 heroku[web.1]: State changed from starting to up

Too easy.

One thing confused me though: How did Cody know that I was using Webrick? I emailed him and asked.

His response:

I mistakenly typed some bogus characters in at the end of my address bar while I was on your site…something like this: http://www.leandomainsearch.com/search?q=up^jf

Sure enough, Webrick fails loudly when the URL includes a caret: