LinkedIn Twitter Facebook

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. His business interests include a diverse range of industries from manufacturing to property to technology. As a technology commentator he has a broad presence both in the traditional media and extensively online. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

More about Ben here.

22 responses to “Intuit Launches the IPP Version 2”

  1. Krish

    An interesting titbit about this platform is that it is built on top of Mindtouch platform.

  2. Dennis Howlett

    @ben: I’m staggered that you’re buying into this ‘platform’ lock-in so readily. Of course it is any app because those apps have to programmatically work with IPP’s API’s. That’s not a done deal for any application. The long term vision may well be no Intuit apps but if you look at what they’re offering now it wouldn’t make any sense for an add-on developer to do anything other than dev against QB etc.

    As to the assertion it shouldn’t matter whether it is a Google/M$ stack I don’t understand what you mean. There isn’t a Google ‘stack’ per se. I see they’re talking about Adobe Flex but have they said anything about Ruby apps where there is a huge amount of investment?

    It says it allows apps in regardless of tech stack but making that work is a world apart from saying it.

    The biggest problem though lies in what I am currently seeing in the pricing model. At the rate they’re going, I might as well invest straight into Force.com or AppExchange because costs are going to mount very rapidly. At least with SFDC I have a mature model with hundreds of applications to choose from.

    And then what about market specific needs. Intuit is very much US focused so how will they carry this idea outside the US?

    One to watch, but with care methinks.

  3. Ben Kepes

    @Dennis – thanks for your comment. The reason that IPP appeals is that it doesn’t create lock in the way a force.com does. It’s an integration model rather than one that relies on apps appearing within the platform. A such it’s a continuation of things such as FreshBooks Service as a Network notion. My understanding is that applications can be part of the platform regardless of what they’re written in – I’d need to confirm it but I’d assume this would include Ruby. The fact that there are multiple points of integration would suggest that making it work would be easier than on (for example) a force.com type PaaS offering. I’ve spoken to vendors who indicate that the revenue share is similar to that expected with other channel partnerships – this one however has the attractiveness of playing to a reasonably qualified audience. As for market specific needs, the important thing here is that it’s not a QuickBooks play – as such it should be less regionally-centric than other apps.

  4. Dennis Howlett

    @ben: you have to be really careful on this stuff because in truth all the current iterations of PaaS are at best half way between product and service.

    You say no lock-in but I don’t see anything about working with other services etc and fundamentally I’m not sure I see much difference between this and AppExchange/Force.com – you’re still working within the context of a model that Intuit specifies. In Force.com etc, add-ons become another tab in the main app. Here it seems I have to build against…IPP which is proprietary to Intuit. I’d be far more impressed if it went the other way but that isn’t happening.

    Multiple points of integration make things MORE difficult not less. There is a mathematical formula that expresses it. With the Force.com you have a single point of integration -much simpler though still a lock-in.

    You say it is not a QB play but that’s the only core app in the marketplace so how is not going to end up a QB play? Otherwise there’s very little incentive to play unless you think there is some sort of advantage in effectively using IPP as a reseller channel. Their own blurbs say: “Rapidly build and deploy rich Software as a Service (SaaS) apps capable of seamless integration with QuickBooks data.”

    But let’s put all of that aside for one moment and assume I am completely wrong. All past attempts at this have failed – the list is starting to get fairly long.

    Anything to do with money doesn’t travel well unless it is incredibly simple. Intuit doesn’t have a track record of stepping far outside its territory. There’s history here.

    Anyhoo – the proof will be in the eating and for that we’ll all have to wait and see.

  5. Intuit makes two-pronged PaaS and SaaS push | Software as Services | ZDNet.com

    [..] ,CloudAve. [..]

  6. dahowlett

    Looks like I am right on lock-in: http://blogs.zdnet.com/SAAS/?p=779

  7. Intuit’s IPP will cause a stir but will it shake up the saas world? | AccMan

    [..] (IPP.) The first report I saw in this was fromBen Kepes who declares: [..]

  8. Alex Barnett

    @Dennis,

    thanks for the healthy skepticism :-)

    you asked about which stacks IPP supports for Federated Apps into IPP: “It says it allows apps in regardless of tech stack but making that work is a world apart from saying it”

    I can confrim that one of the apps is built on Java. Another is built enirely 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 an app built on Google’s AppEngine. It doen’t matter – the integration points are just that and pretty lightweight (one of the partners was able to turnaround the work with 1 developer 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.

    Also – just to make clear: apps not have to integrate with QuickBooks data – this is optional and up to the developer. But, as in the case of VerticalResponse, the fact that it does means that the relevance of their app to those QuickBooks customers increases hugely.

    thanks,

    Alex Barnett,
    Group Manager, Dev Relations, Intuit.

  9. Federated Apps on the Intuit Partner Platform - Alex Barnett blog

    [..] Ben Kepes, CloudAveIntuit Launches the IPP Version 2 [..]

  10. dpilling

    Interesting debate about lock-in. Frankly, I tend to agree with Ben, this is an integration framework, not an infrastructure play. There is no technology lock-in, but there is definately channel lock-in. Seems to me that the decision for the app developer comes down to whether or not they want to leverage Intuit as a channel; a tech facilitated channel. And if this is a channel play, then I believe the app. developer should expect to give up billing, login and user management/permissions control. If Intuit’s channel is not important to you, don’t develop to the framework and build your own channel.

  11. ian sweeney

    Ben,

    We quickly realized building the product was half the battle, the other half is building the billing/collection system (the irony of billFLO building a billing system isnt lost on me!)

    Can you speak in more detail about the billing component of IPP? If the Intuit billing/collection system can be leveraged, this could certainly accelerate time to market for startups.

    Ian

  12. dahowlett

    @alex – thanks for the answers and I also tuned into the show with Phil today. As you know I’ve raised a number of other questions on my own blog (don’t these things have a habit of growing?)

    Would be good to get your feedback there as well as get a session with you at some stage to walk through the implications.

  13. Ben Kepes

    Hi all – thanks for the feedback

    @Dennis – I see IPP as being completely different from force in that the same saas product (let’s take vertical response as an example) can run standalone or on IPP – it’s entirely the same thing. To run on force however it needs to be re-architected to work on that platform and sits there irrevocably – that’s lock in.

    @Dennis – I like the multiple points of integration because it means a vendor can choose which parts of the IPP offering they use – maybe just billing, or maybe just data integration – it’s a veritable buffet of options.

    @Dennis – you say previous attempts at this have failed yet Coda2go is surely a success story for joining in with partnerplays? Personally I am looking forward to another SaaS accounting app going live on IPP to give us all a hgiher degree of confidence

    @Derek – agreed – this is a channel rather than a technology play. Personally I believe most vendors will be happy to be locked into a platform that has such a large addressable market – especially when they consider that the lock in doesn’t stop them dealing with other channels (their own, other PaaS, other partners etc)

    @Ian – I believe the billing component can be leveraged by other vendors (I’m pretty much sure of it) I’ll ask Intuit to comment in more detail

  14. Ben Kepes

    @Krish – no it isn’t – from Intuit “we use mindtouch for doing cms stuff on the dev website (techinal content), but that’s it.”

  15. Alex Barnett

    Ian,

    I thought your comment about spending half your time on building a billing system so you can sell your SaaS app was interesting, as this is just one of the problems we solve for SaaS providers.

    In your case (where you have the SaaS app built, deployed, etc), you can use our Federated Apps model to package your SaaS app and sell it to Intuit Workplace customers. Currently, we provide you with the ability to provide a Free Trial version of your app (up to 30 days) and a paid for version (by defining the price of subscribing to the app via a web UI we provide to you). Intuit collects the money from the subscribers of your app and then pay you monthly the subscription revenue for all your subscribers (minus the rev share % we charge you).

    Hope this helps!

    Alex.

    Alex Barnett,
    Group Manager, Dev Relations, Intuit.

  16. dahowlett

    @ben – sorry to say but you’ve clearly not been on the sharp end of integration issues. Good luck selling that story. You miss my point completely on this but then I guess you’ve not seen how others have fared. Sorry to sound rude but it is clear you have little clue about the practical realities of getting this stuff done. By all means bang the end user drum but without answers to these fundamental questions then who exactly is going to come to the party?

  17. Ben Kepes

    @Dennis – actually I’m an end user of a number of integration situations and hence totally understand why the IPP play is difficult but sensible. I’m not sure if you realise but I’ve been involved with a large number of SaaS integrations and see IPP as making life easier in a number of situations.

    There are 5 apps that are up and working and I for one am looking forward to seeing more.

    Luckily I’m not selling a story, rather espousing a strong opinion, loosely held…

  18. dahowlett

    Sorry Ben – I have to disagree. As an end user I fully understand your position but as a developer?

  19. Ben Kepes

    @Dennis – no problem re your disagreement, and thanks for the discussion thus far. Let’s reconvene in this one once the IPP has had a chance to bed in…

  20. Krish

    Gotcha, thanks. Sorry for the wrong info then. Got the idea from this tweet :-)

  21. Parsing Intuit’s IPP: much to consider | AccMan

    [..] and today I caught up with Alex Barnett and Alex Chriss from the company to explore what it means and where it might go. Prior to that conversation I spoke with Ben Kepesand [..]

  22. Zoli Erdos

    Nice to see Dennis is coming around :-)