One of the older apps in our toolkit, django-waitinglist, is one of our more valuable pieces of software.

[[|django-waitinglist]] allows us to quickly take an idea for a site, stand up a landing page, and gauge interest, and most recently, start getting a good sense of early customer segmentation.

There are three apps in one in this package:

  • waitinglist
  • surveys
  • cohorts

At the core, this app is pretty simple. It records email addresses of people that want to either be notified when the site launches, or get in line to be invited to a private beta.

The notion of cohorts was added fairly recently relative to the long lifespan of this project. This feature enables admins to group people on the waiting list to send private signup codes via email in batches.

The most recent feature addition to this Django app are surveys. You can create simple surveys in the Django admin and then when you make the survey active, people signing up will be presented a form to answer questions you have constructed. This can prove invaluable in getting an early sense of the types of people initially drawn to your site through the messaging on your landing page.

=== History ===

This core bit of code is some of the oldest we have and still use today. It pre-dates both Pinax and Eldarion as it was something that James Tauber had written back in 2007 for the [[|Habitualist]] prototype. It was later pulled out as an independent package to be used as a reusable Django app.

=== Getting Started ===

This type of app makes the most sense to use early on, most likely, before you even have code for a site, but at least while it's still in closed signup. We use it almost exclusively as the first thing that gets added to a new site created with the [[|Account Starter Project]].

We turn off open sign up:

{{{ #!code python


Then we install django-waitinglist by adding:

{{{ django-waitinglist==1.0b10 # latest release at time of this post }}}

to {{{ requirements.txt }}} and to {{{ }}} we add:

{{{ #!code python INSTALLED_APPS += ["waitinglist"]


We then do what we are doing in the site to create the tables (syncdb, South migrations, or nashvegas migrations).

=== waitinglist ===

We dress up a home page with a brief pitch about what we are building, add a logo, and then add a simple form for email addresses with the following tags:

{{{ {% waitinglist_entry_form as form %} {% include "waitinglist/_list_signup.html" %} }}}

We can monitor the admin to get see the signups fairly easily.

=== surveys ===

Then, once deployed we go into the admin and add some questions that we want to ask the signups, which we make optional, and generally free form text. Our goals with this are to identify early customer segments that are attracted to our pitch. This helps a ton in customer discovery/development and we get a really good sense very early on what types of people our value proposition is attracting.

=== cohorts ===

When we are ready to invite users to the site to run a private beta, we will naturally pick users from the signup, but even more importantly we like to group users into cohorts instead of inviting them all at one time or randomly.

This allows us to do cohort analysis as during this phase of site development things can and will change rapidly based on usage and feedback from each successive cohort as well as our own intution and roadmap of features that were not present at certain stages.

Using the cohorts tool, you can create and build cohorts of whatever sizes you want and invite the cohort in blocks. Each cohort is simply a labeled list of entries in the waitinglist.

When users get an invitation, they receive an email with a special link that allows them to signup even though signup is closed. These are features that depend on [[|django-user-accounts]] that we use on virtually every site we build and comes preconfigured in the [[|Account Starter Project]].