Intuit Partner Platform team blog

Focusing on the Future with Intuit Anywhere

Developers: you’ve talked and we’ve listened. We know there are two key things you want from the Intuit Partner Platform (IPP): access to QuickBooks data and access to QuickBooks customers and we want to make that as easy as possible. Here’s what we’ve heard from you that is not an ideal experience as a Federated app today:

• You wanted to allow customers to access your app anywhere, including via the Intuit App Center AND your own website.
• You didn’t want to have to use our billing system or user management.
• You didn’t want create a new version of your application just for our channel and therefore support two versions of your applications.
• You want us to use industry standards for authorization and Single Sign-On (SSO).

Based on all this feedback (and more!) we introduced Intuit Anywhere in August 2011. Now we’re pleased to announce, also based on developer feedback, that we’ve made the decision to decommission Federated applications and continue to invest and focus on Intuit Anywhere.

What does that mean for you?

• New Apps – All new apps need to be built using the Intuit Anywhere components. Be sure to check out the Requirements Checklist so you know exactly what is required as part of your app’s integration.
• Apps in Progress – If the security review for your Federated app has already been started, you may continue with Federated.  If your app has not been scheduled for a security review, please transition to Intuit Anywhere.  
• Existing Apps – Existing Federated apps will have plenty of time to migrate to Intuit Anywhere. By July 1, 2013, you need to make sure your Federated app has been decommissioned and all of your customers have been migrated to your integration using Intuit Anywhere

While this will require changes on your part, it’s important to note that the bulk of the work (integrating with QuickBooks via Intuit Data Services) does not require additional changes. Here is a quick look at the biggest differences:

• You will need to implement OAuth and OpenID. 
• You may need to establish your own billing system and user management (if you don’t already have that for your non-federated SaaS app). The best part of this is that you will no longer need to support two version of your application.
• You will need to adopt our updated revenue model. Rather than Intuit retaining 20% of your revenue every month, you’ll only pay Intuit $5 a month per company-connected, regardless of users. More information on the Intuit Anywhere billing details are here.

We’ll be hosting a webinar to answer all of your questions on Thursday, June 14, 2012 from 12pm-1pm PT. Please sign up to attend our webinar to if you have any questions about migrating to Intuit Anywhere.

We’re very excited to announce this decision allowing us invest and focus on exactly what you want! Thank you for continuing on this exciting journey with the Intuit Partner Platform.

Thanks,
The IPP Team

ProOnGo: Ushering in the Era of QuickBooks-Compatible Mobile Apps

The following is a "guest" blog post, by Phillip Leslie is Founder & CEO of ProOnGo LLC, maker of ProOnGo Expense and numerous other QuickBooks-compatible mobile apps. He can be reached at phillip at proongo.com

----

Thinking about building a mobile app that connects to QuickBooks? Welcome. There has never been a better time to do so!

Lets review. Just five years ago, of about 219M mobile subscribers in the U.S., just 9.1M of them hadever used a “downloaded application”. Today, there are far more than 9.1M new smartphones being sold-through to consumers every week, and mobile apps go hand-in-hand with unwrapping a new smartphone.  Combine that with the fact that there are 4.5M companies running QuickBooks, and you’ve got all of the ingredients for putting the power of QuickBooks into the hands of on-the-go businesspeople everywhere.  Want to be sure that the folks carrying smartphones are the same folks that want to get to QuickBooks data on-the-go?  Try looking at time-series relative search volume for the terms “QuickBooks Mobile” or “Intuit App”, and you might find yourself running, not walking, to your mobile app engineers.

Before You Do File→New Project

Before you crank out the first line of code, you might put some thought into your revenue model, because it may impact your architecture.  For this post, I’m going to assume that you have a SaaS revenue model, because that’s the clear trend amongst Intuit App Center apps in general.  At issue is the question of whether you should plan on building a mobile app that connects directly to Intuit Data Services, or whether you should build a mobile app that connects to your own web server that enables or supports the data flowing to and from Intuit Data Services.

If you decide on a SaaS revenue model, you’ll probably want the primary flow of data to pass through your own web server, rather than directly from the mobile app to Intuit Data Services.  That way it’ll be a lot easier for you to manage access rights based on business rules around your subscription packages.  I’m not saying this is the only way to architect a SaaS app, but it does seem to be the most mainstream approach.  For the purposes of this blog post, I’ll assume that you are building a mobile app that has a SaaS revenue model, and that you’ll use a custom server-side in part as a passthrough for inbound and outbound data being exchanged with Intuit Data Services.

First Things First

You are going to need some way for users to sign in.  You could homebrew your own account creation, sign in, and authentication code.  Whatever the reason, that seems to be a popular choice.  However, I’ll bet that you don’t consider your sign-in process to be the core of your differentiation, and if that’s the case I’d suggest letting someone else bear that burden.  Specifically, by relying on an Intuit Account sign-in with OpenId integration, you can rid yourself of the responsibility of building a sign-in and authentication system from scratch.

Want to know which sign-in pages Intuit has optimized for viewing on a mobile device?  Try launching your web browser with a User-Agent that urges Intuit’s web server to send you a mobile-formatted version of the page. For example, on a Mac with Google Chrome, you could open your browser window via a shortcut like:

open /Applications/Google\ Chrome.app --args -user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3"


Launching your browser with that type of User-Agent, for example, causes the App Center sign-in page to show you it’s mobile version:

 

 

 

If you’ve built any mobile apps in the past, you probably already know how to get an embedded web browser into your app (Android: WebView; BlackBerry: BrowserContent; iOS: UIWebView). You can easily point an embedded web control to Intuit’s URL, to let the mobile device’s native browser handle the rendering and user interaction of Intuit’s mobile-formatted sign-in page.

Once you’ve got a skeleton app that presents this mobile sign in page in a probably full-screen web control, you’ll need to put some thought into a strategy for doing an OpenId assertion driven by your custom web-side code, to complete the cycle of establishing a session between your mobile device and your custom server. And, you won’t have to write a lick of password storage or retrieval code. Thanks, OpenId!

Tackling the Try-Buy flow from a mobile device is an advanced topic for another time — but the above should get you going if you’ve already got a desktop-side Try-Buy flow that is the primary starting point for first-time users.

Hybrid App Basics

I’ve already urged you to hand Intuit the responsibility for maintaining the sign-in UI, and to use OpenId to cause your device<=>server session to be authenticated by Intuit. If you do all of that, then you are probably at a point where you are thinking about hiding the embedded web control upon successful sign-in, and thinking about how to transition to your native UI that exposes the main functionality of the app.

You’ve heard that hybrid apps are all the rage, and that HTML5 is making hybrid apps even more attractive, and anytime you find yourself mixing embedded web controls with native UI you are essentially building a hybrid app. So, how does a hybrid app maintain the continuity of device<=>server session when it’s initiated via an embedded web control, but later used by your app’s network connection code (like Android: HttpURLConnection; BlackBerry: HttpURLConnection; iOS: NSURLConnection)? Although there may be some oddball exceptions, the vast majority of device<=>server session management for embedded web browsers is handled via session cookies. The rules by which the session cookies are issued and invalidated end up being specific to web server, configuration, and server-side code base, but a search for the following terms will lead you to abundant information about the most popular session handling semantics: JSESSIONID, PHPSESSID, ASP.NET_SessionId, sid.

Once you nail down the nature of your web server’s Set-Cookie headers (try Firebug or Chrome Developer Tools to verify your understanding), you are well on your way to writing mobile app code to manage the hand-off of the relavent session cookies from your embedded web browser to your customized device-side network connection code.

Consuming and Sending Data

At this point, you have a user that is authenticated by Intuit, with a session established between the mobile device and your server, and we’ve made the assumption that the Try-Buy flow was handled via a desktop-side first-use experience. If you’ve made it this far, you are in a position to begin exchanging data with IDS via your server, with the sends/receives either happening synchronously when your mobile app requests it, or asynchronously to do some predictive caching of resources that you anticipate your mobile app will need frequently. If you’ve written much web service code for use from mobile devices, you’ve probably settled on a RESTful design, and my suggestion would be that the mobile<=>server interactions should pass XML bodies that conform to the IDS data models. After all, if the destination or source of the data is IDS, and if you are aiming for a seamless integration with QuickBooks, it seems undesirable to invent an intermediate XML schema for mobile<=>server interactions. If you are worried about the “heaviness” of some of the IDS-returned XML bodies, you could certainly cull the nodes that you know your mobile app won’t consume.

I’d recommend having class definitions, parsers, and serializers for the IDS objects that you rely on most heavily. Without getting into the always-heated debate of what design pattern is most appropriate, let me suggest that in basic terms you’ll want to be able to pass around IDS objects in an object type that makes sense on your mobile device.

For example, on iOS, having objects that conform to NSObject puts you within striking distance of being able to conform to additional protocols (like NSCoding) that will take some of the load off your developers when they get around to implementing local caching of IDS objects.

We’re Out of Time, But…

There is so much more to say, for example, about:

• Managing asynchronous connections to make the QuickBooks data-driven scenarios “feel” just as snappy as if they were local to the device
• Developing a caching strategy, and a method of keeping track of dirtied objects and resolving conflicts
• Using the server-side to shield your mobile device code from having to know whether the data source is QBO or QBD

…however, these and other topics will have to wait for a future post.

Phillip Leslie is Founder & CEO of ProOnGo LLC, maker of ProOnGo Expense and numerous other QuickBooks-compatible mobile apps. He can be reached at phillip at proongo.com

 

Partnerships, IPP + Windows Azure

When we started the Intuit Partner Platform, we had a pretty simple vision: To delight Small Businesses with an ecosystem of applications that solve lots of needs and work extremely well together. We set out to build a platform that would enable us to work with our partners to build more and better offerings for the small business community. 

Although the vision hasn't changed, the path along our journey has certainly evolved. Three years ago, platforms-as-a-service were nascent. To help accelerate our partners getting to market, we created and offered an end-to-end platform. This helped a number of our partners get to market, but it wasn't a perfect offering. It was a stack that solved the needs of a small set developers, but couldn't scale in features to meet the needs of all our developers.

While we've continued to invest in our native platform, other platforms have moved at lightning speed. Many of these platforms focus on what I'll call the "lower" end of the stack. This is the stuff a developer needs to build and deploy a saas or mobile app (hardware, database, etc.). These platforms have evolved way past anything we could create and honestly provide a better development experience than we could.

In parallel however, we've focused on our core assets and differentiators, and evolved the "upper" end of the stack. This includes access to QuickBooks data and key "go-to-market" services that make app integrations possible and delight small businesses. As you can see with our Beta release of Intuit Anywhere, we're continuing to push the envelope on providing ubiquitous data integrations and tightly integrated apps to our customers. That's what we're good at, and it's where we will focus now and in the future.

That brings me to a couple of announcements we shared at IPP CloudJam: First, we will no longer offer our "native development" stack for developers to build on. We are going to focus our resources on the top of the stack and make data and services for our developers the top priority.

So what should our developers who are looking for a PaaS offering do?

While we have always been and will always be an open platform, and we will always embrace applications built on any platform, we think it's important to help guide our developers who are looking for a PaaS option to what we believe is the best option on the market. So I'm pleased to announce that we will continue the journey we started with Microsoft last year and double down on our investment to tightly integrate the Windows Azure platform with IPP. The feedback from current developers using Azure and live on Intuit App Center has been extremely positive and we believe with additional investment in our Windows Azure SDK for IPP, we can make developing an app on Azure, leveraging Quickbooks data and IPP's go-to-market services, and getting into the Intuit App Center Channel, DROP DEAD EASY.

We've been extremely impressed with the dedication and quality of Microsoft's platform, their willingness to work closely with our existing partners, and their dedication to making developers successful. Microsoft has built a huge business behind their partner community – they just "get" how important partners are and how to treat them – and with our "native" IPP development option now gone, we think this is the best platform for our developers.

Read up Liz Ngo, Microsoft's business development manager on why we're doubling down on this partnership. 

Here is some more information on how developers can take advantage of our partnership, sign up for Front Runner for IPP. 

Look for new releases of Window Azure SDK for IPP in the coming months and if you have requests, feedback, or interest in learning more about Azure, please let us know!

Alex Chriss
Director, Intuit Partner Platfomr

Intuit Anywhere Beta - come and get it!

Today, we're very excited to share with you that Intuit Anywhere is now in Beta, meaning you can get a hold of the bits and access the services to start integrating them into your SaaS apps.

 We’re obviously very excited with Intuit Anywhere and to now be at a place where we can share Beta with you - we truly believe that Intuit Anywhere will create brand new opportunities for our partners and awesome new experiences for our customers.

This morning, we walked through an example use case, involving MethodCRM, Mavenlink, Freshbooks and Bill.com. We showed how Intuit Anywhere was acting as the glue across these apps, letting the data flow from one app to the other, flowing into and out of QuickBooks: there was customer data being written and estimates being created in the CRM app, finding their way into QuickBooks Online, then the that same information being read in by another 3rd app - Mavenlink in this case - to create work items and deliverables, which can then later be used by other apps to invoice customer (such as Freshbooks) and bill and pay vendors (via Bill.com).

The walkthrough showed how all this allowed the customer to save time and money by avoiding double data entry, using multiple apps that work together - and doing so at the developer's sites, not through Intuit App Center - that's a really important point about Intuit Anywhere: we want to make IPP's data services available to apps without those apps having to be fully Federated into IPP...

The bluedot widget

We showed how the "bluedot widget" allows navigation across the Intuit Anywhere connected apps, and how it enabled a Single-Sign-On experience across the Intuit Anywhere apps.

We also showed how Intuit App Center acts as the destination where the customer is able to control which apps they've granted permissions to connect to their dats, and how they can control that access, revoking access as necessary.

All awesome time-saving features that developers can integrate into their apps and in turn offer to their own customers quickly and easily.

We demonstrated how Intuit Anywhere was acting as the glue across these different apps.

Then the Bill.com team showed a live demo of Intuit Anywhere that they have rolled out to a some of their customers as part of the early-adoption program. They also shared the customer feedback - all very positive feedback, really validating the value we're delivering to to developers and customers. It was awesome!

That was the customer facing story.

We then had the product team demonstrate how quickly and easily IPP developers can integrate Intuit Anywhere into their apps and get the data flowing between their apps and IPP data services APIs. All real bits, real services - they got an app integrated in minutes, real-time in front of the developer audience.

And you can get going yourself right now!

Before you head off and review the docs, here are a couple of very important pieces of info we shared this morning at IPP CloudJam since our initial announcement a few weeks back:

Intuit Anywhere - Pricing:

For each Intuit Anywhere connection, Intuit charges the developer $5 per company connected per month. There is no limit on the number of users – so an app that is connected to a company file can be used by multiple users.

Also, we’re not putting limits on how and if the developer want to charge customers for leveraging the Intuit Anywhere feature. Developers can choose to include the cost as part of their standard pricing, or pass the cost on to the customer as a monthly feature, or  add their own margin, so for example, charge the customer $10 per month, retain $5 and pass $5 to Intuit.

We want to keep this pricing as simple as possible and give developers the choice around the economic opportunities here.

Intuit Anywhere - Timing:

Today you'll be able to access a pre-release version of the bits and services you need to integrate the Intuit Anywhere experience and data into your app.

We plan to make the first set of Intuit Anywhere integrations available to end-customers in late September, with a phased roll-out of other Intuit Anywhere connected apps on a “First Ready / First to Go Live” basis.

Intuit Anywhere - Types of Apps Supported

Eventually (as the name suggests!), we want to make Intuit Anywhere available for all types of apps and services, and across every device.

To start with, we’re focused on enabling web-based SaaS apps that are sold to multiple customers – if you have a mobile extension for your SaaS app – that works too.

Over time, we’ll add support for custom apps and integration: examples are one-off integrations between QuickBooks and ERP systems, or other “behind the firewall” integrations. Stand-alone mobile and iPad apps and "desktop" applications won't be supported in the first instance, but we plan to. We don’t have a timescale to share for these, but if you are planning to use Intuit Anywhere for custom, mobile-only or desktop apps, we definitely want to hear from you and will update you once we have a roadmap to share.

--

So, you can get going and start your integrations today. The team has worked very hard to make sure that the developer experience is quick and as simple as possible – the reality is that the grunt of the work developers will need to do will take place around the integration of the data into their app. If you've already begun this data integration - then that's great: Intuit Anywhere is using the exact same data service APIs that are live today on IPP, just using OAuth, so any work on the data integration will be totally ready to go when we go live with Intuit Anywhere.

As you can imagine, the developer experience is a top priority for us - we want to make it as quick and simple as it can possibly be.

And we want the customer experience to be awesome too - we want customers to trust the that the Intuit Anywhere experience will be secure and "just work", so each integration needs to meet technical requirements and pass a security assessment prior to going live.

Lastly, the point of the Beta is to learn and get your feedback, so we very much look forward to hearing from you as you start your Intuit Anywhere integrations.

So...if you like the sound of Intuit Anywhere, come and play with the Beta!

-

Alex Barnett
Group Manager, Developer Relations

Announcing IPP Support for QuickBooks Online - Open Beta

It's been a while coming, but we're very excited to announce that the Intuit Partner Platform is now well on the way to expanding its support beyond the QuickBooks Desktop product to also support QuickBooks Online.

Today, the IPP Intuit Data Services for QuickBooks Online API is now available as an open beta for all developers building applications on IPP, and you will be able to start selling your QBO-integrated IPP apps through the Intuit App Center by January 2011.

About the QuickBooks Online Customer Base

Intuit’s small business customer base is increasingly moving online to manage their front and back office functions. Intuit has seen this trend firsthand with the impressive growth of QuickBooks Online. In one year, QuickBooks Online has doubled their customer base...and 80% of these customers have not previously used QuickBooks Desktop.

As an IPP developer you now have the opportunity to provide additional value through building applications that integrate with QuickBooks Online (QBO) data, filling key customer needs and providing great solutions to Intuit's fast growing QBO customer base.

We'll be driving a ton of users to your apps: with one click, a QuickBooks Online user will be able to immediately access (try and buy) a list of IPP apps that specifically integrate with QBO data - all while using their existing QBO username and password.

Benefits of Early Adoption

Our main PR launch is currently scheduled for January 2011. Get in early to be part of this exciting launch which will include direct access to our QuickBooks Online customers through in-product links.

As an early adopter of IPP's Intuit Data Services (IDS) for QBO API, you’ll also help shape our development roadmap. We’re very interested in learning what you need as we expand and evolve our offering.

We’re very interested in your feedback on documentation, the data objects you'd like supported, and API functionality. Discuss feedback at the IPP forum.

About the API

Many IPP developers are already familiar with the Intuit Data Services API that supports the QuickBooks Desktop data model. For QBO, we're following the same REST-based, broad data model, however there are some key differences.  Over time, we aim to make these differences even smaller.

The initial set of objects we have in the beta today are those that we plan to be in the final V1 release, and each today have full CRUD operations. These objects are:

• Account
• Bill
• BillPayment
• CashPurchase
• Check
• CreditCardCharge
• Customer
• Employee
• Estimate
• Invoice
• Item
• PaymentMethod
• SalesTerm
• Vendor

Filters and Sorts are available for each, see docs for details.

How to get more info on the open beta:

• Review the IPP Intuit Data Services (IDS) for QBO API documentation
• Attend the IPP IDS QBO API overview webinar (Friday, Oct 8, 2010 10AM-11AM PDT) - Register here
• Meet with the IPP team - Sign up for the IPP CloudJam at Intuit's offices, Nov 17-18 2010, Mountain View, CA - (We’ll be doing sessions on the QBO API).  Tickets are limited (we only have 25 left) so register asap.  

Thanks,
The Intuit Partner Platform Team

Ruby web apps and the Intuit Partner Platform

Editor's note: The following is a guest post by Zack Chandler who has been active in the Ruby on Rails and Intuit developer community for a number of years.

As recently as five years ago the majority of developers considered the Ruby programming language arcane and obscure. Then the Ruby on Rails web framework burst on the scene and seemly overnight became a must-consider choice when building web apps.

I began working with Ruby on Rails before the 1.0 release and have been amazed at the progress of the framework and growth of the community. Not long after that I began developing integrations between Ruby web apps and QuickBooks via the QuickBooks Web Connector and QuickBooks Online via the QBO API.

New to the QuickBooks ecosystem, I quickly learned there were additional benefits beyond simply adding the “QuickBooks integration” checkbox on a feature tour. Specifically the QuickBooks Marketplace quickly proved itself to be a valuable channel for lead-generation.

Fast-forward to 2010 and Ruby developers have even greater reason to be excited with Intuit’s current integration opportunities.

Ruby web apps apps targeting small to medium-sized businesses are launching daily. Humm… guess which accounting system most small to medium-sized businesses use (hint: rhymes with “fast cooks”)?

Meanwhile Intuit has re-imagined their entire developer offering and launched the ambitious Intuit Partner Platform. To a Ruby developer with no former experience with QuickBooks integration I would simply say that the most exciting parts of IPP are:

• Intuit Data Services - a cloud-based API for QuickBooks data
• Intuit Workplace App Center - an online portal where your web app can be marketed and sold to millions of Intuit customers

I recently did a deep-dive into IPP and came away thoroughly excited. I’ve posted a quickstart tutorial entitled Intuit Partner Platform for Ruby Web Applications on my Depixelate blog which will hopefully help other Rubyists get started with IPP.

The future is indeed bright for those Ruby developers wishing to both co-market and integrate with Intuit data through the cloud.

Windows Azure SDK 1.0 for Intuit Partner Platform Now Available!

As part of recent joint announcement by Intuit and Microsoft, we released a beta version of the Windows Azure SDK 1.0 for Intuit Partner Platform - a set of tools, code samples and services designed to make it easy for developers of SaaS applications developed on Windows Azure to federate those SaaS apps on to IPP and sell them to millions of Intuit customers in the Intuit Workplace App Center.

So What's New?

I'm pleased to announce that version 1.0 is now available for download (if you are already a project member you can get the source code directly at code.intuit.com). So, what's new in 1.0? The main change is the support for Intuit Data Services (IDS) that makes it easy for developers to program against customers' QuickBooks within their applications. We've also included an IDS-integrated sample app to help you along.

Get Started with the Windows Azure SDK for IPP
Here developers will find documentation with the steps to host an application on Windows Azure and federate it in to the Intuit Partner Platform. The document provides step by step instructions to get the requisite accounts, create the project for the hosted service, program against IDS, and finally, to federate the web application in to Intuit Workplace. Additionally, the document also provides the steps to configure the SAML Gateway’s endpoints for SSL.

View the Azure Documentation.

Happy Coding

-Jarred

IPP - Alterity's Story: From the Desktop to SaaS

It’s always exciting when a new app goes live on the Intuit Workplace App Center, and especially so when it is has been developed by a long-standing member of the Intuit Developer Network.

Brian Sweat of Alterity had good conversation (full recording as an mp3 here) with Redmonk’s Michael Coté to talk about the new Easy Analytics for Inventory, and why - as a 10-year-long member of IDN developing "traditional" desktop applications - Alterity is adopting IPP and the SaaS delivery model for the next generation of its products that integrate with customers' QuickBooks data.

Show Notes:

• Brian tells us about Alterity and their new offering, Easy Analytics for Inventory.
• I ask Brian to tell us how they started getting interested in using IPP and what the process was like getting up and running.
• We talk about the use of Flex and how the IPP platform integrates with the UI layer.
• Brian tells us about the ability to more closely track what users are actually using and doing (or not using) in a cloud-based application.
• While customers don’t seem to be overly concerned with cloud vs. desktop deployment – at this early point – Brain says the support and even install time on cloud seems much smaller than for traditional deployment options.
• This leads to a discussion about the other effects a PaaS, like IPP, has on a company’s structure: namely not having to worry so much about billing and other back-office concerns. And then there’s all the marketing Intuit does for them in the App Center.

The full recording as an mp3 here.

Intuit Partner Platform + Windows Azure = Win for Small Businesses

When we started the Intuit Partner Platform (IPP) last year, we envisioned a destination where Small Businesses could pick from a variety of quality applications to solve their critical business pain points – and we wanted those apps to work together!  A big ecosystem of Apps – from a variety of developers and pre-integrated – solving for the needs of Small Businesses.

Today, we’re thrilled to announce an alliance between Intuit and Microsoft, that brings IPP a giant step closer to our ecosystem vision. Starting today, SaaS developers can access the beta of the Windows Azure SDK for IPP - a set of tools, code samples, and services, designed to make it easy for developers of SaaS applications developed on Windows Azure to federate those SaaS apps on to IPP and sell them to millions of Small Businesses in the Intuit Workplace App Center.

Today’s news about Intuit and Microsoft’s relationship has two converging themes:

1) More developers + great tools = more great apps for small businesses

• The Windows Azure SDK for IPP (when fully delivered) will enable developers to build a great application on the Windows Azure platform while leveraging the go-to-market services (i.e. single sign-on, billing and data web API’s, user management, etc.) of IPP and publish their app to an existing marketplace in the Intuit App Center.
• In addition to the third-party developer apps, Microsoft will also be working closely with us to offer their Business Productivity Online Suite (BPOS) via the Intuit Workplace App Center.  While it will take a little while to get the integration just right, we think the addition of BPOS, to the Intuit Apps, and third party apps, creates a strong suite of apps for Small Businesses to choose from.

2) Broader channels = more customers for developers

• By reaching out to our respective Channel partners (VAR’s, Solution Providers, etc.) and introducing them to the Intuit App Center, we further expand the ecosystem of Small Businesses that developers can target. Through our product channels (via QuickBooks) and our partner channels, we have an opportunity to build a large customer base using connected applications.

The reason we’re so excited about this alliance is very simple: More Quality Apps + More Targeted Customers = Vibrant Ecosystem (and a strong network effect)!  By joining the development and channel forces of two of the leaders in the Small Business Market, I think we have a great opportunity to delight SMB’s, Developers, and VAR’s. Win-Win-Win!

Alex Chriss
Director, Intuit Partner Platform

IPP Podcast Now Available by Michael Cote (RedMonk) and Jeff Collins

This new RIA Weekly podcast talks about what IPP is, and the opportunity it represents for developers.

Enjoy!