This Is Locomotion - Design, Code, and News

We’ve been busy preparing the MediaCore Cloud for launch, and have been looking into how to handle the recurring billing as we plan on offering monthly plans. Initially we were considering building our own recurring payment solution (or implementing one built by a payment gateway), but after some research we found that there are a number of amazing SAAS recurring billing services. Notably, these include:

• Chargify
• Recurly
• Spreedly
• CheddarGetter

In distilling things down further we started by doing a quick search on Quora, and it seemed like most people were either on Chargify or on Recurly. Our good friends over at New Bamboo have used Chargify for Pusher and have never had a problem, and our friends over at MetaLab have been using Recurly for Flow and also have very positive things to say. So both services have passed the social validation check for us.

Digging in a little deeper we found a number of really useful graphs over at Matt Mazur’s blog that essentially showed how the services compared in cost as your subscriber base grows.

The big takeaway here is that Chargify is substantially cheaper early on as they offer lower pricing for your first customers. As the number of customers increases, then the costs of the services roughly equal out.

The next big factor in making a decision on whether to choose Chargify or Recurly boiled down to the feature differences between the two. We’ve drawn up a little feature chart to show off the differences between the two initially.

Let’s go through a couple of the big differences that we see between the two platforms:

Interface Design

There really isn’t much of a comparison here, Recurly wins hands down. Chargify’s interface is considerably less polished, and they really haven’t paid attention to many of the small details that makes Recurly’s interface hyper-useable. As we’re an interface design company, these little things (although not critical to our decision making process) do bear weight on our overall opinion of the service.

Customizeable Emails and Mailing List Integration

Although both systems do dispatch emails, Recurly’s are more user-friendly by default, and are also a lot more customizable. After playing with both platforms, I would prefer to send customer’s emails via Recurly. Another nicety of Recurly is that they also offer mailing list integration, so it’s possible to easily take your subscriber list, and link it up with tools like MailChimp to email blast your subscribers about new features, company news, etc.

Packages / Addons

Using Recurly it is possible to create a Addon (some people might call it a package) that is bundled with a payment in addition to the recurring monthly charge, so if for example you are selling subscriptions to a blogging service, and a customer chooses to add a theme that costs $9, then Recurly will charge the customer their monthly fee, plus the extra $9 for the theme they bought. This is a great feature for anyone who is up-selling subscribers on additional one-time purchases. Note: Chargify does have similar functionality. See the comments by Chargify’s founder.

iPhone App

Chargify really leads the way on this one, providing you with a great iPhone app that gives you all the quick business data you need such as the number of signups you have received that day, the number of customers you have, and your revenue figures. Handy!

VAT Support

Recurly supports charging VAT on items, which will make people who are building SAAS apps in Europe and need recurring billing very happy. Sadly, Chargify does not offer this feature. Note: This feature is coming to Chargify. See the comments by Chargify’s founder.

Intelligent Payment Routing

Recurly has the ability to route payments to the appropriate gateway based on easily configureable rules. This feature can help with avoiding paying unnecessary fees, and can help in unlikely event of a payment failure as it will fallback to the secondary payment gateway if you’ve added one to your account.

Gateway Support

Both Recurly and Chargify offer support for major payment gateways, but they don’t both offer the same ones, so depending on which gateway you want to use one may be a better fit over the other.

Chargify supports:

• Authorize.net
• Beanstream
• PaymentExpress
• QuickPay
• TrustCommerce

Recurly supports:

• Authorize.net
• Beanstream
• Braintree
• Cybersource
• First Data
• Intuit
• Litle & Co.
• Paypal Payflow
• Paypal Website Payments Pro
• Sage Card
• Wirecard

On Paypal w/ Recurly: we tried Recurly with Paypal Website Payments Pro for a recent project, and had nothing but problems with PayPal as we found it dropping around 10% of transactions. Switching from Paypal to Braintree solved the issue, and since  implementing Recurly with Beanstream for a client we haven’t had any issues.

The Card Store

Up until now we’ve been looking at some of the minor differences that separate Recurly from Chargify. Perhaps one of the most major differences between the two services is that Chargify does not keep the card store on it’s server, instead it stores the data with your merchant account of choice. The problem here is that if you decide to switch merchant accounts, you are left in the position of having to persuade your merchant account vendor to release your card store, which they are very reluctant to do in most cases. Recurly keeps the card store on it’s own servers, so if you decide to switch merchant accounts for any reason (ie. to get a better rate) then you don’t need to worry about switching and getting your data since Recurly holds the information. You can read more about this on Chris Compton’s blog here (the article was written before Recurly re-designed their service, but the core point still applies.)

Final Thoughts

After some careful consideration, we’re close to deciding finally on choosing (drumroll…) Recurly as our subscription billing platform of choice. The main factors affecting this decision include:

• The Card Store: The fact that Chargify does not keep the card store
• Payment Routing Support: Recurly’s intelligent payment routing support (although we don’t need this feature now, it’s definitely something we may need to use in the future)
• Number of payment gateway choices: As our service grows, it’s nice to have a broader range of payment gateway vendors to choose from, especially since switching gateways in Recurly is relatively straight forward.
• Interface design: We really do like the interface that Recurly offers over the interface that comes built into Chargify.
• API ease of implementation: We’ve taken an in depth look into both Recurly and Chargify’s API’s. On the whole, Recurly’s documentation is better, and flexibility of their API is superior.

We’ll be looking forward to providing an update on our findings in a couple of months. If anyone else has further remarks on the differences between the two services we’d love to hear them!

On Saturday, April 30, 2011 at 10pm EDT (GMT -4), we will begin migrations to a newly provisioned host server. There will be some downtime while your VPS is migrating. We generally do not expect the downtime to exceed 15 minutes, but it is based on many variables and may (rarely) exceed a half hour. The MST will be actively monitoring your host machine for the duration of the migration. If you have any questions, please contact us.

Exciting things have been happening at Simple Station for the past few months, and we thought that we should take a little time to update our website and share some of our latest creations.

What’s new and happening?

• The very shiny new Simple Station website
• Completely overhauling our MediaCore Video Platform giving it a complete visual facelift, along with some hefty new features. Our design team has sweated blood on this project, and we’re so excited to see it go live. MediaCore has been getting some great press recently and big organizations such as the University of London have started using it
• Designed and built 6 great new web apps over the past few months. Head over to our portfolio to have a peek at our new work. You can click the little “i” at the bottom of our portfolio (best viewed in Safari for maximum HTML5 coolness) to read a little more about the project and the work that we’ve done
• Amazing new icon design work – just go through the portfolio and you’ll see

We’re hiring!

• We’re also ramping up our staff for the summer and are actively looking for a Python developer. If you’re awesome and want to work for a great up and coming company, get in touch with us

This year we’ve got some pretty huge things planned and we can’t wait to start really making a big splash.

I’m finally getting around to updating Locomotion with a new blog article. Over the past 2 months we’ve been super busy working on our MediaCore Video CMS, and have been concentrating a large amount of our effort into building the platform out.

During this time I’ve also had the opportunity to attend a Masters Photography workshop in Florence Italy with the New York School of Visual Arts in New York. From a photography perspective the course was excellent and I really felt like it deepened my knowledge of both my camera and photographic techniques substantially. I’m definitely looking forward to taking a lot of the material I learned from this course and applying it to all kinds of various client projects; taking the time away from web design to experience a completely new medium has been both refreshing and invigorating creatively.

Once the course wrapped up I was off to the UK to continue working on MediaCore and drum up some more European clients while preparing to deliver a series of speeches at the EuroPython conference in Birmingham. I’ll have to make a separate post in the next couple of days on what I learned in prepping for those presentations, but suffice to say that I learned more about speaking in a week at EuroPython than I had during my entire time at university. Nathan and Anthony also presented and learned a lot from their presentation during the conference. They are now off on some much needed R&R for the next week. Anthony will be spending his time in the north of the UK, while Nathan is off to Paris.

At the moment I’m currently situated in Amsterdam as we pause for a week of work, and am finding that I absolutely love how the city blends 16th-17th century architecture with contemporary interiors. Transportation is good, a beautiful canal structure winds throughout the city, and watching everyone commute to work on bicycles has been pleasantly refreshing. The design scene is well established and I’ve met the teams from Sofa and SoGeo, both of which are running exceptional businesses. I’m looking forward to another few days of exploring Amsterdam, and I’m sure I’ll get a chance to post a few photos.

Everyone will be back in the office by August the 2nd, and we’ll be heartily at work cranking out the next version of MediaCore.

Recently Apple’s CEO Steve Jobs wrote an open letter discussing Apple’s stance on Flash. As you may know, Flash is not permitted to play on the iPhone, iPod, or the new iPad. Here are a few choice words on the matter from Mr. Jobs:

Flash was created during the PC era – for PCs and mice. Flash is a successful business for Adobe, and we can understand why they want to push it beyond PCs. But the mobile era is about low power devices, touch interfaces and open web standards – all areas where Flash falls short.

The avalanche of media outlets offering their content for Apple’s mobile devices demonstrates that Flash is no longer necessary to watch video or consume any kind of web content. And the 200,000 apps on Apple’s App Store proves that Flash isn’t necessary for tens of thousands of developers to create graphically rich applications, including games.

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too). Perhaps Adobe should focus more on creating great HTML5 tools for the future, and less on criticizing Apple for leaving the past behind. Source: Apple

A representative of the browser software company Opera also chimed in with a few thoughts:

“But at Opera we say that the future of the web is open web standards and Flash is not an open web standards technology. Flash does have its purposes and will have its purposes, the same as [Microsoft's] Silverlight and others, especially for dynamic content. But flash as a video container makes very little sense for CPU, WiFi battery usage etcetera – you can cook an egg on [devices] once you start running Flash on them and there’s a reason for that.” Source: TechRadar

Even Microsoft’s General Manager for the Internet Explorer, Dean Hachamovitch, had nothing positive to say about the future of Flash:

“The future of the web is HTML5. Microsoft is deeply engaged in the HTML5 process with the W3C. HTML5 will be very important in advancing rich, interactive web applications and site design. The HTML5 specification describes video support without specifying a particular video format. We think H.264 is an excellent format. In its HTML5 support, IE9 will support playback of H.264 video only.” Source: Microsoft Developers Network

Apple has thwarted Adobe’s efforts at every step of the game in bringing Flash to the iPhone platform, and Adobe is now responding by requesting an antitrust inquiry into Apple’s new policy of requiring software developers who devise applications for devices such as the iPhone and iPad to use only Apple’s programming tools.

Adobe really ought to take Jobs’ advice, see the writing on the walls, and start building HTML5 tools instead of wasting it’s time complaining.

At Simple Station we couldn’t be happier to see Flash slowly going the way of the dodo. We stand behind open standards, fast loading interfaces, and interactions that make good common sense; we will continue to recommend open-source solutions over Flash to all of our clientele.