The Demise of the QuickBooks Third-Party Developer?

I remember meeting Brad Smith for the first time and commenting to myself, that this guy was something special – still the most humble and honest friend I have known all these years; people like him only come around once in a lifetime. It is easy for us to criticize Intuit at times, but I challenge anybody to walk in his shoes for a week.

It was a time of excitement for me, as it was the first time I was involved with the big name ‘Intuit’. And I helped man the booth for QODBC/FLEXquarters with whom I had partnered, after pestering them for months to be a part of their team.

Everything was first class – a fancy food layout with jumbo shrimp… and Haagen-Dazs Ice Cream!

The SDK and the Development Rush

It was a year or so before this, when the SDK (Software Development Kit) first became available, and developers lined up to get involved. I had later heard from Intuit’s founder Scott Cook that he had to “fight” with his team to open up the QuickBooks system to others. People wanted access to their data, and their frustration would finally be removed.

Well, it was nice while it lasted.

In the beginning years, developers all found some ‘niche’ that focused on what QuickBooks didn’t have – Scott Cook’s dream a.k.a. “one size does not fit all”. However, if you look at the developers who have ‘survived’ from those early years, you will find that they have one thing in common: Their product doesn’t solely depend upon QuickBooks. Exceptions noted, but for the most part, developers creating tools for QuickBooks’ missing features, have ended up as sole proprietors doing custom work or moving on to other things.

In my early years in the Intuit world, my company focused on QuickBooks integration – and I was stubborn in my belief that our team could create re-usable code. But the price to create those custom integrations was higher than the market would bear, and no matter what it was, everybody used their QuickBooks files differently, so that if something changed, the program wouldn’t work – and of course the customer didn’t understand that. I didn’t blame them.

I barely got out with my shirt on my back, and concentrated on the data extraction, business analytics, and report writing business. Best decision I ever made – albeit a few gray hairs later.

During my time on the Intuit Accountant Council, I had the pleasure of getting to personally know three gentlemen in charge of the IDN (Intuit Development Network): Harvey Alcabes, Peter Vogel, and Ed Schaffer. Ed was the ring leader, and was great in helping us to solve problems, Harvey went out of his way to accommodate new developer SDK requests, and Peter was a genius; he coded the original QuickBooks web connector while sitting in the backyard of somebody’s BBQ party! And Shannon Atkins – who was the glue in that team; she kept everything fresh.

That team was actively involved in developer conferences, meetings, group activity, and personally assessing feedback.

But sadly, that time and those methods have passed. In the last few years, at the various conferences – including Doug’s Accounting Solutions Conference – I would make it a point of asking other third party developers if anybody had reached out to them, or if they had even seen somebody at the conference from Intuit who represented the developers. The answer was almost always no.

Oh sure, there are some who have made some personal relationships, but in general- the tone, two-way participation, and camaraderie is nothing like it was in those first years. No roundtables for feedback, no national gatherings.

Additions to the SDK have technically kept up with the yearly editions, but that is because it is necessary for Intuit to write back to their own products when communicating with cloud applications. But I can’t use the word ‘timely’ to describe each release to the developer.

I remember one year, the SDK wasn’t even available until months after the QB release. On another occasion, I recall that while developers were asking for the budget information to be exposed; it was being used by the Intuit Statement Writer – but not available to them. Only to find out it WAS there, but nobody bothered to tell us – until a year later. Even in the most recent SDK, the additional fields for contacts were shown to be exposed, but we soon found the data itself was not available. Yes, eventually fixed, but at a later date.

There are still items not exposed, and the Intuit canned response to developer’s requests for those items has always been “what is the business case?”. My tongue-in-cheek answer has always been – “because the people worked hard to put in their data, and it belongs to them – NOT you.”

As I learned, during my work inside of Intuit, there were some technical reasons, but I formulated by observation two mentalities: One that said “we decide what data is important for you – not you”, and another that said “we are gung ho on version 1, but we may not get version two or three complete”. There is some semblance to these statements, as I have found out.

If anybody wants to take exception to this, I will be glad to debate a decade’s worth of interactions to prove this point. This not about personalities – it is about fact.

From the SDK to the IPP

Isn’t the SDK supposed to be over? We are, after all, moving to cloud applications. New QB users are flocking in high numbers to QuickBooks online.

Well, there are still millions of desktop QuickBooks users, and developers need some way of creating a bridge between their application – desktop OR cloud – and QuickBooks.

Intuit’s answer to this was the IPP or Intuit Partner Platform. It has gone through several name changes and iterations since its inception, e.g. Intuit Anywhere, Intuit Data Services, but it is still about providing QuickBooks data in the cloud. I actually helped the original architects during my 2 ½ year stint there a few years ago, and the idea was good, but the implementation had problems – generally in the area of synchronization. The learning curve was steep, and the technology was not ready for prime time. I saw this first hand.

The original intent of that program was to allow developers access to data in the cloud – using a Platform as a Service model where all the developer had to do was build a product using tools provided by Intuit, and Intuit would take care of the rest: hosting platform, collection of monies, etc. They also allowed ‘federated’ applications whereby an existing third party application could hook into the QuickBooks cloud data.

However, the results – years later – are less than stellar, from any objective measure.

Go to the current Intuit App Center- and you might be stunned at the low number of applications using the Intuit cloud data extraction methodology and wanting to be listed on the App Center. You hear about Apple or Android creating applications in the hundreds of thousands – but there are only 60 or 70 (10% are Intuit’s own offerings) in the App Center.

Furthermore, if you go the Intuit Marketplace – which contains all applications using both the SDK and the IPP, there are only several hundred –and some of those applications have been extinct for a while.

This is the demise of the QuickBooks developer. Our developer community has gone from sizzle to fizzle.

What Happened?

While the current stewards of that program aspire to a larger list of offerings, there is a history of problems that began to evolve long before they got there – and they have compounded over time.

First, I want to make it clear that these are my own opinions for this turnaround of events – and are not representative from anybody in The Sleeter Group or its associations.

Secondly, while some Intuit employees may take offense to my opinions, I am making my conclusions based upon personal observation, private conversations with other developers, and as an actual third party developer. Even good employees may have honorable intentions, but they don’t always have final say over the decision making process – and unfortunately end up at the point of our wrath instead of the decision makers.

Lastly, I call these ‘golden nugget’ criticisms. The fact that many of us have survived is a testament to the development outreach from Intuit, including its programs and offerings; many of us are blessed to be making money in this space.

However, we are going backwards – not forwards. This is my premise.

1. IPP suffers from lack of data availability compared to the SDK. I know Intuit has made promise after promise, to make all the data available ‘like the SDK’, and it has never come to fruition
2. Intuit keeps changing the model. The reality is that if developers had written their products for that first IPP iteration, they would have had to RE-write it two or three times to use the current iteration. Not just simple changes, RE-writes. And the billing issue, as first promised, must now be implemented by the developer.I personally know of one developer who, several years ago, made an attempt to move their product to use the Intuit cloud offering, and lost a whole year of development in doing so, eventually saying “Intuit couldn’t keep its promise”. The developer eventually reverted back to the SDK and created his own mechanism to bring the QB data in the cloud. There are many companies who have finely honed their methods of synching their cloud applications with QuickBooks desktop using the SDK – and they have no plans to change. Intuit wants to move developers over to the cloud model – but the reality and theory are still far apart; and some have already been through the wringer.
3. SDK developers are penalized for using what works. IPP developed applications are moved to the front of the line in terms of visibility to the general public, but because the implementation is a subset of the SDK, developers are penalized for using what works best for them.
4. There is no sense of ‘development community’. Intuit does not go out of its way to reach out to developers in a personal way or create a sense of camaraderie and community. Part of this is generational – as some may be more comfort in a Facebook type of communication setting. Part of it, is that it is not a priority, and may lack funding resources. Furthermore, they may not want to hear our war stories – they are not always pretty. Personal PR takes a lot of time and effort, and I can’t remember the last time I saw a survey to developers about what we thought of the current program and its offerings.
5. Intuit will do version 1 but may neglect version 2 or version 3. There is an interesting conundrum at Intuit. Many times they will go through several iterations of something to get it right, but there are other instances where they never quite complete an initial offering. The SDK is still missing pieces after all of these years, the IPP is still far from being what is optimal, the ODBC (‘Custom Reporting’) views in Enterprise that originated three years ago are STILL missing critical pieces for people to be able to use all of the components.
6. Intuit will eventually build it on their own. Intuit always has a ‘we can build it better ourselves’ mentality. I don’t necessary fault Intuit for this approach, as it is their right to add functionality to their products – and many customers would rather have the feature IN QuickBooks. But I have seen instances of an attitude that purports “if we DO build what we are doing, we don’t owe you an explanation, and frankly that’s your problem.”There are two sides to this coin. Some third party developers have created better applications than Intuit has been able to reproduce, or Intuit actually withdrew their competing offering. But there are also other cases where developers were at odds with Intuit in terms of what they were told, and what transpired. There is a lingering trust issue in certain corners of the development community, and many say “why should I even try?”I don’t want to criticize the basic Intuit ethical model – I know Brad wouldn’t tolerate ethical breaches. However, I do know aberrations have existed, and some still linger.
7. The shareholder is king. Bottom line is that Intuit’s primary objective is to take care of its shareholders. The various Intuit communities and the resulting interaction are important pillars, but unless it benefits Intuit directly, it won’t get priority. Business reality.
8. Questionable importance of third party applications. Years ago Intuit publicly purported statistics about the large number of users who depended upon some type of third party applications. Are those statistics about other Intuit products? Or non-Intuit third party applications? What is the true target market for developers? The statement ‘millions of QuickBooks users’ is not a true statement of the actual target market for non-Intuit third party applications.

What Does This Mean For The developer?

Regardless of what Intuit does or doesn’t do, there are still choices and opportunities. If you currently develop applications that integrate with QuickBooks, you have already made your decisions, and you will make the best of it – or move on. Many of the aspects of development I have described in this article are no strangers to long time QuickBooks developers.

However, if you are considering new development in the QuickBooks space, here are my ‘two cent’ tips:

• Don’t build an application that QuickBooks will eventually put into its products. If you think that Intuit will buy your product, think again. If you have an application that increases a sizable market share, and is more effective to buy as opposed to build – and is worth millions – then maybe.
• If you do build something, produce one of two types of applications:
  • Standalone applications that happen to integrate with QuickBooks, but don’t wholly depend upon it.
  • An application that – if it does depend upon QB – has advanced features that Intuit would most likely not address, e.g. it is a specialty product that isn’t for all QB users.
• If you happen to build something for the masses that QB does not do, just know that you have a two to three year window to make your big splash. If it is popular, that will be the next thing that Intuit will put in their product. You may in fact have a better offering – and do BETTER after Intuit puts their iteration of the technology in its product, but just be careful of picking your poison.
• Make your choice of data extraction methods, based upon what is – not upon what is promised. Some things are beyond the best intentions of Intuit employees.
• If you continually ask for data that is not available, and it does not come to fruition, then know it will most likely only be available if it benefits something Intuit will build. Resources may not literally be available in their current planning cycle.
• Involve yourself with the Intuit Accountant and Pro-Advisor community – but don’t force yourself upon them. Get their input, and advice; and if you don’t know anything about accounting find someone that DOES. Call Doug Sleeter or Bonnie Nagayama.
• Find other developers to engage with. Some of us have been around for years, and can tell you about the trials and tribulations of QuickBooks development. We may tell you to run away as fast as you can, but we have good intentions. Even the competitors in a particular space talk with each other.
• Be your own island and move to your own beat. There was a time where I constantly wanted to know about what Intuit was doing, but I have learned over the years to just take care of my customers. You or I can’t control what they do, and it is a waste of time that we could be using to improve our offerings.
• When Intuit decides to put something into a product that somebody else has already built, there are three considerations: Ethical, legal, and public relations. If you approach Intuit, you need to consider the ramifications of all three – just like Intuit must.
• Lastly, think LONG and HARD before engaging in this business. You will be frustrated, and you will have days where you wonder why you ever pursued your aspirations in this space. You will be told of ‘Millions of QuickBooks’ customers, and ‘diamonds in the sky’ – and you will have a hard time separating reality from fiction. But, if passion is your true ally, you take care of your customers, and are careful about your target development market, you might survive. Just keep your eyes open.