Shop Update: Course Correction

As you may be aware, we’ve been been working hard on producing what we aim to be a really great commerce solution for your Perch and Perch Runway based sites. This week we’ve sent out a rather different build to our testers, so we’d like to update you on the progress and on those particular changes.

We were intent from the outset that this shouldn’t be subject to some of the compromises you might encounter when integrating separate CMS and ecommerce solutions into one system, but should provide the best of both – really good ecommerce backed up by the great content management you’re used to.

To achieve that with the small team we have here at Perch, our plan was to integrate with Moltin to make use of their excellent ecommerce platform with out needing to reinvent the wheel, and we proceeded on that path. As we progressed, however, we began to re-evaluate the needs of Perch customers, reassess what makes Perch a unique and interesting product, and revise what we’re doing as a result of that.

As a result, we’ve decided to build an independent ecommerce solution rather than continue with any sort of third-party integration. The Perch Shop will be stand-alone just like all the existing apps you’re familiar with. For those of you who are interested in the reasoning, I’ll go into that a little bit below.

Time to think again

When it came to integrating with Moltin’s API, there proved to be a lot more work required on the Perch side than we anticipated. Things that we had hoped would be abstracted away (like the need to implement specific code for each payment gateway) turned out to be more involved that we planned for. There were also a few issues here and there (as there always will be with any software platform) where we needed to wait for Moltin to fix, test and deploy new code.

It was second point that gave us pause for thought.

With Perch we’ve become accustomed to being in control of the product. If there’s a feature customers need, or a bug that needs fixing, we’re in complete control of how and when those needs get addressed. As you can imagine, hitting up against even the smallest problem with an external API can be a source of frustration for both you as the customer, and us as the helpless man in the middle. That’s not the sort of service we want to be providing.

Those selling digital products to EU countries found that the tax system didn’t support current EU VAT rules. We’ve been in discussion with Moltin about us implementing our own tax system on top of their API, but the hooks we needed to do that weren’t as simple to put in place as was hoped.

Rachel and I sat down and look at all these issues. Taking into account the amount of gateway-specific logic needed in Perch, the work Perch is doing to display, manage and edit listings, the inability to fix things when there are problems, and now the potential for needing to implement our own tax system on top, we began to ask how much benefit we were really getting from building on top of a third party API. The honest answer is that we were getting some benefit, but we didn’t feel that it was enough.

Plan B

So we began building a version of the Shop app that doesn’t rely on a third party API. Everything is self-contained within the app (or the three Shop, Products and Orders apps) so it’s just like all other Perch apps in that regard. For handling payment gateways, we’ve begun integrating an established open source library called Omnipay.

That might sound like we’re starting from scratch, but we’re really not. All the products, categories, brands, shipping options and so on are already managed within Perch, and then synced up with the API. If we remove the syncing, all that functionality still remains. The parts we need to implement end up being the cart, shipping calculations, order processing and inventory control, plus a bit more work with payment gateways.

This does mean that we’ll have a limited number of payment gateways to begin with. We’ll be looking at Stripe and PayPal as a priority, plus a few others that existing customers on the beta are planning to use (e.g. SagePay and WorldPay). We plan to have a comprehensive set prior to launch, and will continue to add gateways as we go. It also means we can implement some key functionality that has been missing up until now.

This puts us back in control of providing features that have proved so troublesome up to this point, as well as multiple currencies, trade pricing and the new VATMOSS ready tax system. And of course, without all the API requests, everything becomes much faster and more responsive, plus there’s no bills to pay. Perch Shop will still be free to use.

As you can see, I think we stand to gain a lot in terms of development control, features and performance. We will lose a little bit in lost time going over some covered ground, and also inherit more work going forward, but we think this is the right thing to do.

It’s not that Moltin is a bad choice – it’s a really great platform that would be perfect for so many different uses – it’s just not the right choice for our circumstances right now. This course correction is as much about us understanding our needs better as it is about anything else.

Already shipping

A new version of the Shop beta (we’re calling it a gamma!) has gone out to testers this week, already with most of the functionality ported over and a lot of new features besides. Stripe payments are in place and more gateways are being added this week.

Obviously this has been a tough decision to make, but one that we feel is in the best interests of both the product and its users. If you’re interested in hearing more about this, we discuss it on Perch Podcast #52