Hosted apps have unique objections to overcome to be adopted by a customer. Here are three most common objections that I’ve encountered:

Objection 1: Data Safety

<CustomerVoice>

Is my data backed up? How often? Can I easily export my data? What if my hosted app vendor goes out of business or is subject to a regulatory action — what happens to my data? Who else can see my data? Other customers? Sys admins? Who owns the data?

How do I know what you’re telling me about data safety is true?

</CustomerVoice>

Objection 2: Performance

Even profitable, well known hosted applications struggle with performance.

Objection 3: Application Changes

I see this message once a week in at the top of the browser while using Google AdWords:

What if I don’t like the interface change? Can I go back to the old interface?

A Hybrid Approach

I read a lot of blogs and my current RSS reader is Google Reader. But, I’m always on the look out for a better reader. I came across a comment that mentioned Fever. Looking through their web site, Fever looks special — a power RSS reader. The distribution model gave me pause: it’s INSTALLED software — for $30 you get a license and free minor updates; major updates require another payment.

As a customer, installed software doesn’t suffer from any of the objections above. However, installed software is “high friction”: I have to go and arrange for hosting, get backups setup and scheduled, handle updates to the software, etc…

As a software developer, I like the idea of being able to focus on code and 1) skip multitenancy and 2) forget about IT infrastructure for selling a hosted app.

How about this hybrid approach utilizing the open Web App Store API? (see our previous post on an open standard for a App Store for Web Apps)

Here’s the scenario:

Everyone wins. The customer still has hosted app advantages without the disadvantages listed at the top of the article. Fever gets to concentrate on developing software. RackSpace, SendGrid, etc… concentrate on what they are good at. It’s harmony!

The best part is that this is all doable today. All of the cloud APIs needed for this distribution model exist right now.

Think about it — should you be selling your software this way?

There is a very clear battle going on between Twitter and Twitter spam accounts. They join up, then Twitter whacks them. Then the cycle continues. Until it doesn’t.

Either Twitter figured out how to keep spammy followers out OR they just haven’t done it since the first of the year. What’s amazing is how consistent they were for about 3 months (or maybe more, I just don’t have data) and then it changes so immediately.

@adamwride followers in last 3 months

@balsamiq followers in last 3 months

Other’s graphs look very similar:
http://twittercounter.com/ericries/all/followers
http://twittercounter.com/gigaom/all/followers

However, for Twitter accounts that have many more followers, the graph isn’t as jagged (my guess is the proportion of spammy followers vs real followers is much less for these accounts):
http://twittercounter.com/techcrunch/all/followers

Though this account: http://twittercounter.com/cnn/all/followers contradicts that hypothesis (CNN has just a few 100k fewer accounts but still shows the jagged line graph. TechCrunch’s account is smooth with just means that TC isn’t growing as much).

Who has declared victory? Spammers or Twitter?

Vital Stats and Payment

There are many companies that are working on digital wallets. A web app store could integrate with 1 or more of these. This means that the customer only needs to enter vital info once and, potentially, payment information once and then easily share that among all of the different applications purchased.

Customer Acquisition

The web app store creates a marketplace for applications that drives customers to the apps. This means that the application developer cedes a portion of the revenue of their app to the app store since the application developer will be incurring lower customer acquisition costs.

Aggregation

Most tasks take more than one application to complete. I wanted to create a favicon from a PNG logo and it took 3 tools to do the job. Being able to blend multiple applications together into a single holistic solution is extremely powerful since people buy solutions.

Web App Store Road Map

Instead of a closed web app store (like the iTunes App Store), let’s use an open standard. That way, applications can show up in multiple stores or be “added on” by other applications (like BigBrassBand does with Spreedly). The app owner should get to decide which web app stores they show up in and what the pricing is to that web app store. The API should be simple to implement, accessible over HTTP, and return results as XML.

With this in mind, I give the world the Web App Store API (draft).

Here’s a summary (in a theatrical bent):

The Actors

• App Store – The web app store. This could be a dedicated store or an application that wants to be able to include other applications as add-ons. Heroku’s AddOn’s page is a great example of this (you can buy SendGrid service, New Relic service, etc… as you are buying hosting or even after).
• Customer – The person with money who buys applications!
• App Owner – The application developer who is offering a web application for purchase.

The Props

• Agreement – A ToS, Privacy Policy, or other legal notice the customer must agree to before purchase.
• FeatureLevel – A feature level of the product that the app owner is selling. You’ve seen this before — Silver, Gold, Platinum, and Diamondium are all popular names for feature levels.
• SecretKey – A secret string known only to an App Store and an App Owner. This is how an App Owner positively identifies which App Store is calling.

The Script

There are seven (7!) methods in the API. They are all implemented by the App Owner and called by the App Store.

• featurelevels – the list of products available to the App Store. This could just be a static XML file.
• agreements – the list of agreements that a customer must accept to purchase a product. The App Store promises (honest!) to make the customer accept these agreements before allowing the application to be purchased. This too could just be a static XML file.
• customerrules – Does the App Owner require the customer’s e-mail address? Does the App Owner require a username? Are there custom fields that should be presented to the customer? These questions and more are answered by the return from this method — quite possibly a static XML file.
• paymenttypes – the list of payment types (credit cards, Amazon FPS, PayPal [an Adaptive Payments Chained or Parallel payment could be very compelling here], etc…) that the App Owner supports. A static XML file? Almost certainly.
• validatecustomer – This is an optional API and the first one that really, really needs to validate the SecretKey. It checks username uniqueness, that all required fields are present, etc…
• submitcustomer – This takes the same arguments as validatecustomer and returns line items that will appear as a charge summary (product price, sales tax, etc…). This is everything that is required to generate a “Purchase Confirmation — Click Here to Purchase” page.
• activatecustomer – This signs up the customer — just like if they had signed up at the App Owner’s site.

What next?

Dave Winer says on open standards that “someone goes first.” We’ve taken that first step. Now, it’s your turn.

Comment on this open API below: Critique, point out what’s missing, suggest things to change. By firing this standard in the crucible of a public discussion, we can end up with something we all want to use and not have to live with arbitrary store rules laid down by Google or Apple.

This appears to have happened a second time with Metricly getting a nice writeup about their presentation at TechCrunch 50. There are some similarities between BigBrassBand and Metricly and some solid differences as well. I’ll admit the first reaction is a sinking heart. Ugh. They beat us to it.

But then reality sets in and you remember you’ve built a solid product and know that your market responds well to the work you’ve put into your baby.

So, how do we react at BigBrassBand to Metricly getting on TC and getting loads of publicity? Rollin’ up the sleeves. =)

Great little read that highlights the power of marketing, cleverness, and positive thinking.

Where did we end up? BigBrassBand. The beauty of the name only became even more apparent when we got this design from Andy Geppelt @ BlueMonkeyDesigns (we usually work with a designer directly, but this time around we wanted to get as many varied ideas as possible [yes this is controversial, look at the dust storm kicked up at Carsonified re: spec work]).

The beauty of this design was that it put the name of the company in direct “conflict” with the company logo. Most web applications written today are developed by a lone developer or a small team and they are doing their best to make as much sound as they can on the web – not unlike a one man band. So our goal at BigBrassBand is to make your one man band sound like a big brass band!

A little one man band fun:

You’ll know when you’re on to something special, because people will love it so much they’ll tell everyone.

If people aren’t telling their friends about it yet, don’t waste time marketing it. Instead, keep improving until they are.

BigBrassBand is all about giving you the tools necessary to run and manage your business (as well as market your business – with coupons, affiliate marketing and more). We do this so you can focus on building a product that is so fantastic that people blog/twitter/share about you and what you are building without any prodding. No amount of marketing will help if the product just isn’t right. Remember: marketing is just the amplifier.

“I am not worried about the name to be given to the economic and social order that will come after the crisis, so long as its central concern is with human beings.”

Below are subscription pricing options for The Economist (at some point in time):

Notice that option #2 and #3 are the same price, but option #3 comes with more stuff. Why would any one choose option #2? It’s stupid, get rid of it…

When Ariely investigated this and tried this out on his students, he found the following:

• WITH the option present, most people chose #3 ($125). No one chose option #2.
• WITHOUT the option present, most people chose option #1 ($59).

How fascinating! The “stupid” option caused people to chose the higher priced option. Ariely describes in detail why this is — the decision making process is difficult and the brain is looking for shortcuts to help resolve the decision. Put another way, choosing between option #1 and #3 is hard while choosing between option #2 and #3 is easy… so most people make the easy decision.

The implications for pricing and analytics are interesting… you have an option that is critically important but would show up on a report as having no importance. If you were doing A-B testing, you would have to take a “holistic” view of your pricing options (you’re testing menus of options against each other and not individual options).