Musings on the Demise of IPP Native Development
Intuit recently announced that they are pulling the plug on Native development on the Intuit Partner Platform and are partnering more closely with Windows Azure to provide developers with tools to support Federated development on IPP. (The difference – at the risk of oversimplifying – is that with Native development you could build an application from the ground up 100% on Intuit’s platform, but with Federated development you had to build the application on your own platform and then connect to IPP to get at QuickBooks and QuickBase data.) Intuit is also in beta with their new Intuit Anywhere offering, which will be another way that developers can access QuickBooks data from their applications.
As cool as IPP Native development was, I think what really killed it was a lack of adoption by developers. I doubt Intuit would have pulled the plug if there were even a few really hot Native apps out there, and a couple dozen more that people were using on a regular basis. (I don’t know the actual number of popular Native apps, but it seems like 1 or 2 would come
to mind if there was any serious level of adoption out there.)
So what would I have done differently if I was Intuit and wanted to improve adoption by developers? Again, I thought IPP Native app development was pretty cool as it was, but here are a few changes that I would have wished for:
- Fix the billing model - Developers could set their own monthly price for their apps, but then Intuit would take a percentage, and on top of that charge the developer for “megabyte-hours”, which was a bizarre formula that multiplied the amount of data storage customers were using by the amount of time that they used the app. This was scary. In theory, a developer who created a small utility app and only charged, say, $19.95/month for it could end up actually losing money if a customer only set up 1 user on it and then uploaded a bunch of data. And how do you accurately measure how much time somebody spends using a web app? Just give us a simple tiered model, with a fixed cost per month per user, which allows up to a certain amount of data and resource usage.
- Make it easier to create custom user interfaces – This all had to be done through old-fashioned programming. Yes, Adobe Flash Builder has some neat features for creating user interfaces, but it was still a lot of work to connect that to the data and the business logic. With Intuit’s QuickBase product it’s pretty easy to create a decent user interface (although not as rich as I would like), so IPP Native apps felt like a step backward in this regard.
- Support custom applications – IPP didn’t (and I hope they fix this with Intuit Anywhere) support custom applications that aren’t appropriate to be shared with the world at large. The whole billing model and App Center approach just didn’t work for this. At the 2010 Intuit Solution Provider Summit (or maybe 2009, I can’t remember for sure) I asked the Intuit folks why, if the IPP was so wonderful, I couldn’t use it to create a custom application for just 1 client. They looked at me like I just hopped out of a flying saucer. When I posted the same concern in the Intuit Developer Network forums, I got a lecture about why in the world would Intuit want to provide a big multi-tenant infrastructure just to support applications to be used by only 1 customer? (“Look around at this world we’ve made, Equality our stock in trade. Come and join the brotherhood of man.” – Rush, 2112)
- Ignore the 800-pound gray-haired gorilla – There’s partnering with Microsoft, and then there’s partnering with Microsoft. Apparently Intuit has chosen the Yahoo/Nokia approach (combine 2nd- or 3rd-place products [or 4th-place, in the case of the Windows Phone 7 phone] to create the Next Big Thing). IPP Native development committed the unpardonable sin of using Adobe and open source products for development. So what? A platform as ambitious as the IPP has to be open to applications built on multiple platforms (and it still is). Integrating with Microsoft is important, but it’s not the only game in town. It’s hard to believe that Microsoft didn’t put at least a little pressure on Intuit to ditch Adobe Flex, although it’s likely IPP Native development would have gone away without any help from Microsoft.
Now if you’ve been paying attention (and congratulations for making it this far), you’re thinking “Hey, Method Integration does all that!” Well, you can do more in Adobe Flex than you can do in Method, but you can do quite a lot with Method, and the integration with QB is excellent. Salesforce.com also deserves a mention here. It has a richer set of programming features than Method (similar to Adobe Flex combined with Intuit Data Services), but doesn’t integrate with QuickBooks out of the box. For that, you need a 3rd party tool like DBSync and/or you need to hire somebody like me to build the integration for you. Salesforce also offers reasonably-priced billing options for those who just want to use their database services (comparable to Intuit Anywhere) or an application platform that doesn’t include CRM.
My point is not to make a pitch for Salesforce.com or Method Integration (well, maybe a little bit), but to point out that Intuit was up against some pretty solid competition when it comes to providing a complete platform for cloud application development. Much easier to just expose QuickBooks data to other applications, like they’re doing now with the Federated model and Intuit Anywhere.
Nice post – a few comments.
Two flavors of Method. One is based on the SDK – that is what you are referring to in the post. The other is using Intuit Anywhere as was demonstrated last week. While Method is a great tool, the SDK based version may face limitations in the future, because the SDK is most likely going to be frozen – not developed any further.
Salesforce.com – Intuit announced earlier this year that they would have an integration with that. Details aren’t clear though…
The Intuit/Microsoft connection should only apply to Forerunner, the QuickBooks/Azure interface. Intuit Anywhere should be separate from that, I believe?
Custom Apps and Intuit Anywhere – in the blog post at http://ippblog.intuit.com/blog/2011/08/intuit-anywhere-beta-come-and-get-it.html Alex Barnett says “Over time, we’ll add support for custom apps “
Thanks, Charlie – Re: The promised integration between Salesforce.com and Intuit, I suspect it will be pretty basic. The reason I think this is that SF is using Intuit to go after the small business market, but their existing CRM product with full programming features (Salesforce.com Enterprise Edition) costs $125 per user per month. Probably not what they’re planning to offer to Intuit’s customers. However, Salesforce.com without CRM (aka Force.com) is considerably less expensive.
Yes, I think you’re right about Azure vs. Intuit Anywhere. Hopefully we’ll be able to use the latter (and soon!) to build all kinds of cool custom and mass market apps.
Nice article. Our company was a finalist last week at the Intuit App Showcase for our Transaction Pro Importer. We looked at Flex back in 2008 for another product but felt it lacked the features we needed (in this case financial functions). Also we are a VB shop and didn’t want to go through the learning curve of the C# like Flex language. When Intuit announced the ability to Federate we built our solution using Visual Studio 2008 and ASP.net.
I know of at least 2 excellent native apps and I don’t know what the future will be for them. Will Intuit continue to allow Flex apps to run on the platform? Can those developers continue to make changes to them? These are questions hopefully IPP will clarify.
Thank you, John – I look forward to checking out Transaction Pro Importer. I’ve heard great things about your company, and really need to get more familiar with your products.
Mike -
To respond to “I think you’re right about Azure vs. Intuit Anywhere. Hopefully we’ll be able to use the latter (and soon!) to build all kinds of cool custom and mass market apps”….
It won’t be one or the other. The recommended path to developers is to use Intuit Anywhere WITH Azure. But they recognize that Azure is most attractive to developers that need hosting. If you are using Amazon or Rackspace or some other app/db host, you can still use Intuit Anywhere.
Paul
P.S. – cheers on the Method CRM plug!
Ah, OK. So it sounds like there’s just 1 interface to QB data, which is Intuit Anywhere. And whether or not you have a federated application, you still use IA to get at the data.
Hopefully Intuit will make this a little more clear in the near future…
Mike,
Thanks for the article on this. Although there are many reasons why Intuit pulled the native development, this is another example of how they’re failing their partners.
Those developers who partnered with them the most, and did whatever they asked, are the ones who lose the most.
Also, instead of partnering with THE company that solved the whole cloud-app-sync-with-QuickBooks problem years ago, and who got ALL of the data links done well and with incredible speed,(yes, I’m talking about Method Integration), Intuit chose to compete instead of partner. But then, they didn’t invest enough to get it right, or get it done fast enough, so developers didn’t come. They WANTED to come because they loved the architecture, but the platform just wasn’t done yet. As you point out, all the serious developers have been just waiting for a fully-functional IPP platform so they could start developing. But it never came, and now I guess it never will.
Why didn’t they just tell all the developers to use Method (www.methodintegration.com)? If they had, they would all have really good apps by now, plus they would have dozens of consultants in Marketplace who could CUSTOMIZE those applications to extend them beyond what the developer already did.
Mike this was a great article, thank you for the information. I agree with Doug, and can only wonder how this will affect all of us using 3rd party applications.
So.. this might just shake out a bit differently than intended, software upgrades may just be postponed indefinitely for business productivity and stability.
Businesses need people in the know now more than ever, so would you suggest upgrading the software if it would not allow your client to utilize the applications they are currently using?
Hi Karen – I’m glad you enjoyed the article. By software upgrades, do you mean QB upgrades? It seems like that shouldn’t have an impact, because the QB data will always get sync’d with the copy up in the IPP, for any recent version of QB. That part’s not changing. Then if there are IPP native apps talking to the IPP copy of the QB data, that would work just fine. Well, UNTIL Intuit pulls the plug on those native apps. I didn’t check to see if they had some kind of plan for an orderly shutdown of the IPP native apps platform (or have they already done it?!), but I’d be curious if anybody has info on that.
Great article Mike,
I must say I agree with what Doug said. The business logic of Intuit these days is just baffling. I have held off on jumping in to the IPP arena since there was no real clear direction and it did not seem that any of the apps being developed were able to make any money based on the ridiculous pricing model you elaborated on.
For my money, the best app out there is Method and although it does not have the same capabilities as Adobe Flex, it does synchronize with QB seamlessly. Looking at the winners Bill.com, ok that’s cool, two analytic dashboards that look cool, but not sure anyone will really use them and a postcard app, really???
It is becoming increasingly hard to get behind any Intuit initiatives because they are likely to pull the rug out from underneath them when something else comes along.