thanks for taking at look at what we are doing with the Intuit Partner Platform and the great questions you posed.

I think Jeff Collins summarized pretty nicely the overall gist of how we think about it.., but here’s a shot at answering some of these in a bit more detail:

>>1. Past attempts at providing marketplaces have met with failure, one of the most recent of which was the demise of Coghead. How does Intuit believe it can prevent a similar fate happening to IPP?

I think there is a material difference between Intuit’s opportunity and other attempts, and probably the biggest is the size of Intuit’s customer base. We have 4 million small business QuickBooks customers with a potential user base of 25 million employees. From the customer point of view, the mega-trend of SaaS adoption presents new challenges for them, specifically around how all these SaaS apps they subscribe to work together (or don’t). What if all the SaaS apps that they use (back-office and front-office) “just worked” together? That’s a problem we are directly solving. We’re not selling a bunch of disconnected services, but connect services – Intuit’s and 3rd party SaaS apps. We think that’s pretty huge. Another great asset we bring to the table is trust in the Intuit brand.

>>2. I’m less than convinced about Phil’s benign stance regarding vendor side lock-in. Developers that choose to come into the IPP orbit will still have development effort to undertake. How many times will they do that, especially if other platforms emerge?

There are two components to your question: technical lock-in for ISVs and the cost of integration.

On technical lock-in: The five SaaS apps we announced today are developed on a variety of stacks and hosted *outside* of the IPP platform. One of the apps is built on Java. Another is built entirely on .NET. Another is a mix of RoR and LAMP. Another built of Flex (on their own hosting environment – not IPP). If an app was running on EC2, that would work too, as would an app built on Google AppEngine. With Federated Applications it simply doesn’t matter, they can all connect to our platform. From the customer standpoint, they just want great apps – the stack each is built on isn’t important to them.

On the cost the integration points for Federated Apps – these are pretty lightweight (one of the partners was able to turn around the work in less than two weeks, including time for the technical review of the app). We made a deliberate decision to make IPP agnostic to the technology that developers want to use. Yes, we have a “native” stack also, but the options we are providing developers now means there is no technology lock-in to speak of. At the end of the day the cost of integration for our developers is a matter of ROI. If it’s not worth doing, they won’t.

>>3. Is this a direct play against Salesforce.com’s Force.com and AppExchange?

There are similarities, but there are two big differences worth pointing out: 1. You don’t need to be an Intuit paying customer (QuickBooks or anything else) in order to be a customer of any of out 3rd party SaaS apps – this isn’t the case with Force.com and AppExchange. 2. Salesforce.com is focused on the large / enterprise market. We are focusing on the strength of the majority of our existing customer base – the small business market.

>>4. What about interface consistency between applications? That’s something you do get with Force.com but isn’t immediately obvious in the IPP play?

From a UI standpoint, we want to provide a level of consistency across the apps, but at the same time allow the application developers to differentiate via the quality of their UI. We provide toolbar across all apps that provides a common way of sign-in/sign-out, manage the application’s subscription levels, invite users to their instance of the app, access support and help content, and submit app ratings and reviews. We think by working with the developer community there are additional UI elements we can add, but we’re taking a fairly liberal approach to start.

>>5. We seem to be looking at a play which is somewhere between product and service. Why not simply open source the whole thing and put the argument to bed? This would give Intuit a much better chance of attracting many saas players. The fact they only have 5 for this V2 launch seems a bit lame.

We think the #1 reason we will attract SaaS providers to the Intuit Partner Platform is the amount of money they can make by doing so. That said, we definitely see the potential for developers and Intuit around Open Source.

On the number of apps we announced today – many are brand new apps leveraging a brand new capability. They been working closely with us as we productized Federated Apps and wanted a small and manageable number of developers to work with to iron out the kinks. These 5 Federated Apps are in addition to the 23 we already had live on our “native” platform.

>>6. It seems to me that with a smorgasbord of apps to choose from, end user cost could ramp very quickly. What is intuit doing to counsel developers about pricing?

Great question. Most of the developers we speak to have a fairly strong sense of their price points. The interesting this is that our pricing and packaging model provides lots of flexibility – so they can experiment and fine tune – in real time – to find the optimal pricing and features.

Hope this helps!

Alex.

Alex Barnett
Group Manager, Developer Relations, Intuit