The next paper Krish and I are writing over at Diversity Analysis is one looking at subscription and billing services. It’s an area I’ve touched on frequently here and is a relatively busy, and increasingly complex, space. I’ve talked previously about Zuora, Vindicia, Aria systems and have spent much time in the past few days talking to other vendors.
It seems there is a big divide between companies that decide to roll their own subscription/billing system, and those who go with a third party provider. As part of my research I’m reaching out to companies asking what they currently do for S&B services, what they’d do if the were starting again, and why.
So as something of a crowdsourcing experiment, I’m aggregating all the responses I get here in a post. Vendors are welcome to comment below or contact me directly to discuss. Some responses thus far:
Robert Coup – Founder of Koordinates:
we’re not straight SAAS (more marketplace) but we did. Plan is to offload a bunch of it to @TeamXero via API though. [my response was to ask why they went down that route – Ed] There wasn’t anything really suitable. In hindsight I probably would have looked harder, dealing with things like GST is a PITA across suppliers/customers/commissions/etc
Julian Stone, CEO of ProWorkflow:
Yes. Built from scratch to use DPS [a local payment gateway – ed]. Only way to get what we needed.
Ian Sweeney – CEO of billFlo:
we did our own billing data aggregation, billing (sending invoices!) but farm out collection… time to explain our needs = the time for us to build. we have expertise. our needs will change. we want to control user exp.
Jason Lemkin, CEO of Echosign:
Yes because we started 4+ years ago. We also wanted maximum flexibility in credit-card customers and ones to invoice. Not what we would do again. [to which I asked what he’d do if we were starting again today from scratch – Ed] It’s complicated b/c I don’t think any of the services handle BOTH credit card and invoicing well. Zuora is terrific but very focused on complex invoicing for subscriptions. Paypal finally added recurring subscriptions to their API but you have to build it and that doesn’t help with invoicing. They all need to integrate with BOTH Salesforce and your back-end, for us QuickBooks. The start-ups with no funding I am not sure we’d trust. To answer your question, we would use Zuora but it’s still only part of a solution that is more complex that it might at first appear.
Heather Villa, CEO of IAC-EZ:Yes [we built our own solution] – security, dependability, wanting to minimize 3rd parties as much as possible – one less party that payment information has to pass through 🙂 (and one less party to depend on)
Feel free to join in the conversation…
There will always be cases where one has to build a recurring billing app, but I really hope that services like Chargify will save the vast majority of businesses from having to take this path.
As co-founder of Engine Yard, we went through the usual path that leads to getting buried in billing activities, both with software and people. I wrote a blog post all about it that goes into detail and I’ll be echos many businesses: http://tinyurl.com/y8v8qcx
As the majority of common recurring billing functions get wrapped into services like Chargify for a small monthly fee, it just won’t make sense, in most cases, to roll your own.
Instead, all the activities around defining products and pricing, proration, billing cards, declined cards, etc, will be something you outsource just like project management or surveys or email, etc.
A whitepaper to help guide readers towards an answer is definitely needed in this space. From our experience in building billing systems before and now working with companies on Recurly – trends to appear between users who build billing systems themselves vs. go with a pre-built solution.
One big difference we’ve seen is a developer’s prior experience with billing. As Jason mentioned, having the experience of building a billing engine exposes the hidden complexities of “rolling your own” solution. Many of Recurly’s users (including us) have developed our own solutions before and realized what a pain they are to build, and maintain.
Many developers have an incredible amount of experience in building web applications and are qualified to do the same for a billing application. The problem is that recurring billing can be deceptively complex. Getting a credit card to bill successfully one time can be straightforward, but challenges such as how to handle declined credit cards in the future can be tricky- as is handling multiple payment plans, upgrades/downgrades and the like. We put a post together on our lessons learned from online billing on our blog to help save developers from making some mistakes we have in the past. The costs in terms of engineering investment and support time can far outstrip the costs of paying for a more flexible, pre-built solution.
At the end of the day, the decision to build your own billing system or using a pre built system is the true cost of going with either option. Breaking the challenge down into measurable costs (time, $ investment, support costs) really helps inform the right decision. If there is anything else we can help provide in terms of data and suggestions, please let us know. We’re looking forward to your report!
best,
Tim
The decision to build your own billing system or using a pre built system is the true cost of going with either option.