This is the story of Appfail

Over the past 18 months:

• The idea
• The product
• The build
• The launch
• Growing the business
• A reflection

Dr Peter Sbarski: "The Doctor"

First, let's define a failure

When a piece of code running the web site, crashes unexpectedly

Something happens that the programmer didn't forsee

Manifests to end user as:

• An error page
  
• An action not working (eg. 'add to cart' does nothing)

Popular web sites can experience tens of thousands of failures per day

Wouldn't it be nice if...

Our apps automatically detected unhandled errors and reported them to a cloud service with rich failure analytics.

A cloud service which

• Helped us find & fix the failures that actually mattered
• Gave us an indication of failure rates over time
• Helped us track fixes, to make sure they truly work
• Could email us only about failures we care about
• Could SMS us with absolutely critical failures

So We Built It!

Product Goals

• Simple to plug in
• Support multiple languages
• Scalable
• Focus on the web. Do one thing & do it well.

Personal Goals

• Learn new things!
• Work in our spare time
• Very low cost to run

Building Appfail

Started in Jan 2012 & worked for 5 months

Building Appfail: Tech

Code like the cool kids!

• C# & MVC3
• Twitter Bootstrap (heavily customized)
• GitHub (Source & Issues)
• AppHarbor (hosting/deployment)
  • New Relic
  • Memcached
  • MongoHQ
• Amazon
  • SQS, SNS
  • S3, EC2

Building Appfail: Keep It Low Cost

During development, it cost almost nothing!

• GitHub ($7/mo)
• AppHarbor (free)
  • New Relic (free)
  • Memcached (free)
  • MongoHQ (free)
• Amazon SQS (almost free)

We were lean & had no costs!

Challenge Assumptions

Test your ideas & think like a user!

Draw the feature on paper & walk through it as a user.

We:

• Built a major feature.
• It was fantastic!
• A large investment of time.
• When we actually went to use it...
• It didn't make any sense!

The Great Rules Engine Debacle!

Grand idea: Appfail automatically rates 'severity' of failures.

Determined with complex, customizable rules.

For example, a set of ANDed rules based on:

• Exception Type
• URL
• HTTP Verb

Built a complex UI for defining rules, and background worker to execute these rules and assign severities.

Hooked this into notifications - eg. SMS me when an 'Extreme' severity failure occurs.

The Great Rules Engine Debacle!

We were struggling to implement a simple UI

We sat down & said: "How would we apply this to web site X?"

The more time we spent trying to actually use the feature, the more we realised it didn't make any sense!

The Great Rules Engine Debacle!

The truth is: All unhandled exceptions are bad!

They *all* stop the user from performing an action, and they all detract the web-site's brand.

URL Scoping:

Any page failing in a user's path to the order page is equally bad! Eg. the product page, the search page, the category browser.

It's hard to define rules that say exactly what is severe and what isn't.

Marketing

You can't afford to pay for advertising

Don't focus on pay-per-clicks

How else can you drive traffic?

Marketing: Influence the influencers

Launched beta in June.

Our plan: To engage influential people & companies in the dev community.

Here's what happened.

Twitter

We followed a lot of renowned developers on Twitter.

We knew that a tweet from them would bring traffic.

We wished that we had pre-existing relationships with these influencers...

But we didn't.

So, we simply asked them!

Scott Hanselman

Retweeted us on day 1 of beta, to 60,000 followers.

Discussed Appfail in his email newsletter.

This lead to 2,000 visitors on launch day!

50 sign ups in the first few days.

Jon Galloway

Tweeted us, to 10,000 followers.

We wanted more!

We wanted coverage with more staying power...

Something that would stay around longer than 1-2 hours.

We set our sights on the front page of ASP.NET

ASP.NET

Our blog post 'Do you know when your web site fails?' was featured on the front page of http://asp.net for a week.

This lead to 8000 blog post views and hundreds of sign ups.

AppHarbor

In a similar vein, we contacted AppHarbor

They blogged about Appfail a week after we launched beta.

Partner with established organizations

Give them an incentive to promote and sell your product!

AppHarbor Add-On

We integrated Appfail as an add-on for the AppHarbor cloud platform.

This lead to a large number of sign-ups.

You can plug Appfail into any AppHarbor web site in just a couple of minutes.

Organic Search Results

As a startup, you really don't want to pay-per-click for ads.

For a tech-savvy audience, pay-per-click is ineffective.

Pete, with a background in journalism, wanted to run a press release.

Sam was skeptical -- "who would read this blatant advertising?"

Pete won!

We paid to have our press release sent to hundreds of outlets.

We didn't get any top-tier media coverage

But our press release was copied as an "article" hundreds of times

Our organic search rankings went through the roof!

Appfail is in the top Google results for a large array of important search terms.

Devops Devops Devops

Do you have "at-a-glance" visibility of your services status?

If not, how do you know if it's working or not?

We didn't have any devops at launch

We figured -- let's get it out there and see if anyone likes it first.

The problem?

To start with, things will go wrong!

Nobody likes a service that doesn't work properly.

At one point, our service was malfunctioning for 3 days, and we didn't know!

dashing.net

We needed a dashboard...

So Pete built one - open source!

Works on any screen/device

It can display anything

At-a-glance operations dashboard

High level reports that tell us what the service is doing.

We watch this every day, and know if things go awry!

Challenge Assumptions

Don't be afraid to change everything

if the evidence suggests that you should

Put your ego aside, and challenge your assumptions

"Free forever"

During beta, our service was free

We promised "free forever" -- to have a basic, free plan alongside our paid plans

We came out of beta, and launched our paid plans

...and barely anyone signed up.

We tried it all...

We tried restricting the free plan

We tried making other plans more prominent

We tried hiding the free plan behing a small link

But people continued to choose it...

Nothing worked... but we needed to pay the bills!

Could we remove the free plan?

Our users will revolt!

Our users will take to Twitter in their masses!

... right?

So we changed everything

And the silence was deafening!

No user backlash.

No angry social media commentary.

Just paid sign-ups.

Less of them, but paid ones.

Now Appfail had a future

Get over yourself!

As a startup - you're not that important!

You don't have that many users

and they aren't watching your every move

It's OK to change things -- just don't change them all the time.

Don't aim to be a millionaire

Aim to build a product that you love. That you believe in.

Of course, everyone wants to make millions

But it really should be a secondary concern

If you build a product that you love...

• You'll build a better product.
• You'll go the extra mile when things get tough.
• You'll make a product that your users will love.

Don't underestimate the impact this will have on your life.

Running a startup is hard work.

Everyone thinks at the start:

It's OK -- if it takes off, I'll get to work on it full-time.

If it doesn't -- I'll shut it down & get on with my life.

The problem?

Wild overnight success is rare

In most cases, you have to work at it over time.

Initially you have to work, for no/little money to:

• Build a customer base
• Fix bugs
• Communicate with customers
• Add new features

You work 2 jobs, one at work, and one after hours.

This will be hard at times.