Synopsis
> **"Screw auth UX, screw all UX."**... AirPair's UX hasn't been as tight
as we planned these last 12 months. But the blame is not black and white.
We needed serious insights - that we did not have 12 months ago - to get it
right. This is a compilation of knowledge developed from the trenches that
we wish someone shared with us 12 months ago. Whist some lessons presented in
this post are for all levels, many might be fully understood by developers
experienced with building robust auth systems. Even if we had read this, I'm
not sure we would have avoided all the pitfalls without experiecing the
mistakes. That said... For a 20 minute read, just being ***aware*** of some of
this knowledge could save you at leastg 20 days developement or $20k in revenue!
## A UX Apology
If you've used and been frustrated with airpair.com in the last 12 months
(Oct '14 - Sep '15), we'd like to be honest. So were we.
If there's a big take away, it's this:
> "Screw your auth data model or UX, screw all your UX"
Why did it take a long time to fix? The answer is a combination of:
1. Understanding the features we needed for enterprise on the fly.
2. Experiencing unforseen limitations of our model with real customer
interactions.
3. Only 1 developer working on the code base - another story to be told in 2016 ;)
Thanks for your patience. We hope this post will help you avoid traps we fell
into. If you like this post and gave up on airpair.com because of frustrating
UX, we'd like to invite you to give it another shot and let us know whether
you think it's an improvement.
## Authentication lessons learned
Authentication at any real world, non-starter app level is HARD. And we're
all still leaning. He's some pieces of history that lead to decisions that were
made. If I could do it again (with what I know now), I would try to isolate
the transition from chapter to chapter and revamp rather than migrate.
### **Pre AirPair** (2005 - Jan '13)
I learned one more prominent lesson than others after years on codebases
that never saw light of day.
I'd made sites for my own startups on top of the vanilla ASP .net
auth system (.net equivalent of `devise` for Rails) all the way through to
an Enterprise web-based Federated Idententity System for a $100+Bn Australian
bank using SAML Takens, Token Servers, Claims-based authorization - you name it.
Windows Identity Framework (WIF) was too complicated and whilst good for my
gig at the bank, was a ridiculously bad decision and time suck for climbfind.com
even though I'd had attained loads of experience and had a head start.
- - -
**Primary lesson**: Auth is not your business. Until your auth solution is
costing more money and time than writing something custom, stick with a vanilla
solutions - even if the UX seems sub-optimal - to save time writing and maintain
code. If you do even an ok job at your own solution, ods are your custom UX
will be worse for users than vanilla anyway (which is what happened with
ap v1).
- - -
### **AirPair MVP** (Jan '13 - Apr '14)
The MVP was an experiement to see if I could avoid similar development time
sunk into my past unsuccessful startups by finding customers without coding.
I'll always be super proud of how AirPair was bootstrapped to profitability
[How AirPair was bootstrapped to Ramen profitability](http://hackerpreneurialism.com/post/67498528332/how-we-bootstrapped-airpair-to-ramen-profitability) originally posted Oct 2014. and first
to market proving demand for remote coding help via screen sharing.
** Choices **
The MVP consisted of seperate google forms spreadsheets for *customer*
and *expert* "Signup". Email for communicating, google
calendar invites for locking in pairing session times, google hangouts for
screen sharing and collecting and forwarding payments manually with PayPal. We
had 15 paying customers before writing our first lines of NodeJS.
### **AirPair v0** (May '13 - Feb '15)
v0 was about scaling capability without scaling code scaling complexity.
Unfotunately there was not Devise equivalent for NodeJS. PassportJS was
awesome, but it is the buliding blocks underneath a full featured auth system
(password reset, email verification etc.)
** Choices **
To avoid the need to implement things like password recovery / reset, we only
allowed users to authenticate (handling signup & login) with Google oAuth.
This was extremely practical from a development point of view as we could
essentially have one code path for new and return users and implicitly
automatically validate users could join google hangout (google their google
login email).
** Observations **
I feel the decisions at the begining of this phase were really solid. Two
things we observed in this phase:
1. Google auth has a very high drop off and though I believed the drop off
was not and mechanical thing, but rather a natural flow characteristic, my
ex-Cofounder argued poor performance of his landing pages was resultant of
forcing users to auth with Google.
2. Enterprise customers would not use the system as many didn't have a google
account or wanted to use their work details.
- - -
**Primary lesson**: The v0 flow required as a first step for the user to add
company details. This is because the model was built with the concept of a
company which multiple users could belong to. However we never built any UI or
functionality to take advantage of the model. Indeed we even removed this
step on the front-end in v1 as an experiment for higher conversion. Since we
still hadn't got around to building company management, we never put it back in.
Ultimately we wasted time coding, model complexity and probably a few
unconverting customers by jumping the gun. It's very hard and serious insight
and experience are required to know what to build when. I guess I just got it
wrong and the way around it might be to design more tightly separate product
versions with very static goals, rather than migration paths.
- - -
### V1 (Dec '14 - Aug '15)
v1 was supposed to (1) reduce sign up friction as much as possible &
(2) support Enterprise / team usage, it was a
first effort and a great learning exercise to suppor TEAMS. But it wasn't
modeled right, so would ultimately not be fit for Team usuage or do a good job
with indivduals.
** Requirements **
Users could signup or login with either email password credentials or
google oAuth.
** Choices **
The v1 app was released in tandum with the wind down of v0 using an nginx
proxy server to route different urls to the different apps.
** Observations **
1. Doing your own auth is STUPID. Even though we didn't have a choice, we sunk
weeks into trying to get the auth system right. It became obvious that we
underestimated the permutations of use cases of signup up and logging in with
one method vs the other.
2. We couldn't have seen it coming, but Google turned out a horrible choice
for oAuth because over time everyone had multiple google logins which caused
multiple AirPair accounts for a huge % of users without them even realizing it.
This had dramatically bad outcomes for our systems which automatically invited
often a different google email address as the one users were logged in with.
Not to mention splitting usage / history across accounts.
3. Having low friction email login lead to loads of low quality signups and
fake emails and impure analytics. It also DID not increase the overall
funnel conversion, but only that of the earlier steps. I.e. if a customer
is serious, they won't mind oAuth. It's only when people are curious and don't
trust you do they not wish to identify themselves, in which case they just
give you useless crap and undesired noise anywa.
4. People used us for private requirements and company usage, or even multiple
companies. One contact email (as well as single placeholder for billing details)
in our system was not enough and thus neither were our crappy verification
features. Without this built into the model, the UX for our power users sucked.
- - -
**Primary lesson**: Besides being hard to pull of, running 2 apps made
the complexity of use cases un-comprehendable and serverly limited the ability
to migrate the model and simiply new code.
**Secondary lesson**: Building your own auth features are a STUPID idea.
**Lesson 3**: What can go wrong, will go wrong. Stay lean on auth options and
code paths. After seeing the problems of just 2 signup options... It became
apparent how diracted we were from building domain features because we were
being crippled by auth system issues.
**Lesson 4**: Screw your Auth, Screw all your UX.
- - -
### V2 (Sep '15 - ?)
V2 aims to put in place a model that supports Enterpise/team usuage properly
whist keeping complexity as low as possible.
Automation is really important in this release.
We are less interested in lower friction and instead more interested in high
sign-up friction (valid github oauth + 1 email verified + credit card info)
with really high quality user experience once you've shown you're serious and
ready.
** Choices **
The primary oAuth signup / login mechanism will switch from google to github.
The main driver is that most developers do not have multiple github accounts.
A secondary bonus is we get to learn a little about our users straight away
and hook way easier into our github posts publishing flow forking /editing
features.
Before v2 is deployed, we will migrate ALL our user records and avoid
all in-place migration logic and complexity. Rather than start a new codebase.
We're going to throw out as much of v1s auth code as possible.