I was really excited to see that KashFlow had a SOAP API. I have been using www.freshbooks.com which I like a great deal, they have a superb API and developer community. I was recommended KashFlow and have been impressed by the number of powerful features and the speed and response of development. But I was shocked to find that not only is the API a paid-for add-on but its a subscription add-on that doubles the price of owning a KashFlow account! It seems to me that the KashFlow team actually want to deter people from working with the application and extending it rather than encouraging a developer community?
I agree. We had considered creating some modules for a few Open Source programs where we feel KF could tie in nicely. I don't have an issue with paying £100 for development access to the API, but to then sell the module for £xx and the customer then having to pay £100 to access the API as well, it's going to stifle any sales. Thus, we've put development on hold for now, as there are other more productive uses of our time. Jee
Thanks both - it's always interesting to get an outside viewpoint on it all. The logic behind charging for the API is that not everyone wants it - so rather than factor it in to the standard price and have everyone pay for it, we thought it better to keep the price point for the standard product very low and charge extra for API access. I also think that the added functionality achievable by using the API justifies the £8.25 it costs per month. But you both make very valid points and perhaps we've taken too much of a short-term approach. I'm going to have to give it some serious thought. Do you think charging anything is a problem - perhaps a lot less than we currently do, or that it should be completely free?
Charging isn't necessarily a problem. Maybe provide free access to the API, but charge developers a set fee of say £49 for 12 months email support? Or set the API cost to something cheaper. If it was set at £19.99, I would think most people wouldn't even bat an eyelid at paying that if they are going to get extra functionality!
Hmm... had some thoughts on this myself so here's a quick couple of opinions on the above. 1. Have to agree with Jeewhizz and koorb, the added cost is a real stifler on folks wanting to use any API based add-ons. 2. Also agree that charging the API developer for access is a good thing too but if you're going to do that I suggest you go on a staged model... ie: £50 (for example) for initial access so they can do some basic development and decide if it's a workable solution. And then say £100 a year for support. If they want to resell through Kashflow then you can talk about other cost bands.. but the emphasis here is on the product being worth developing and reselling and then everyone benefits. Not the end user paying for an API and then an add-on, etc.. 3. Don't think there's much point in charging for the API seperately for end users as there's no direct benefit or product "API" that they see. What they associate that with is the end product so use the pricing to the developers to take care of that. 4. Consider the "bandwidth" aspect of any API usage and perhaps incorporate in some charges for the amount of interaction and resources used by any API applications. This is strictly a developer/3rd-party-provider cost but it's one to bear in mind early because you don't want the equivalent of a paypal system that refreshes and queries the system every 10 seconds! This sort of metered costing would help reduce that or at least make the developer/provider pay for the resources you'd need to cover it. Beyond that, my comments re: the Paypal side of things still stand from earlier emails.. it's still very much powerseller based pricing and structure. Some kind of banding structure there would be useful for the smaller sellers who only need to get their updates every 24 hours or 2/3 days.
I'm sold on the fact that the API needs to be free for everyone. It'll stimulate 3rd party development which in turn leads to more customers (=revenue) for us and more features/functionality for our existing customers. I've got a board meeting this week so will seek agreement then to get it changed. Duane
Ace... Now, if only you could provide the necessary time compression plugin so I could multi-task my development with wedding plans, honeymoon and work... Although on reflection perhaps I shouldn't multi-task on honeymoon... *cue: strangled gurgling sound*
