Leaving BigCommerce
On October 26 I tried to log into the administrative interface of this storefront to process an order, and I just got a blank screen. After some research and testing of my own, and a conversation with BigCommerce technical support, it is apparent that they have changed their systems - suddenly, without warning - to be incompatible with my usual Web browser. They will not be changing back, and they offer no solution for me to be able to log onto the system except telling me I ought to switch to a different version of the browser. That is a dealbreaker for my continued use of BigCommerce and I am moving the North Coast Synthesis Ltd. Web storefront off of BigCommerce as soon as I can.
I have had my storefront on BigCommerce since 2018. I switched away from Shopify because Shopify did this same thing to me. There was just suddenly a day when logging into the Shopify admin interface didn't work, and their support couldn't offer any solution except telling me to switch browsers. As far as I'm concerned, suddenly and unnecessarily breaking my existing workflow and telling me I need to make an extreme change on my own desktop - which would break a bunch of other things - just to be able to keep my computer and my business working the way they did before you pushed the button, is a hard line. Crossing that line entails losing me as a customer.
In three and a half years of using BigCommerce I've slowly compiled a list of other annoyances and small problems. The biggest of those were probably the issues with multi-currency support. Add an item to the BigCommerce cart while one currency is selected, change the currency, it appears to change when you view the cart, but then when you go to check out it will, suddenly and without explanation, change back to the currency that was selected when you first added the item to the cart. BigCommerce has never recognized the sudden currency change during checkout as a problem needing a solution beyond just telling me to tell my customers "don't do that."
I can select an option that tells BigCommerce to automatically update exchange rates - but if I select auto-update, the rates will always be 2% low, so I'd lose some money on every non-Canadian transaction. I ended up having to write my own "app" to automatically update the rates every day in a way that accurately reflects the rates I get from my payment processor. And coupon codes on BigCommerce seem to be naturally linked to specific currencies. If I want to create a coupon code for "10% off" or similar (as I frequently do for my newsletter subscribers), it will by default only work when the checkout is in one specific currency that was locked in during code creation, giving the user a confusing message otherwise. After some back and forth on whether they were going to "sunset" the older coupon code system that did not have this limitation (but which eventually just silently failed to work), they eventually added support to allow coupon codes to apply in all currencies. Actually creating an all-currencies code requires an extra step and generates confusing messages in the admin interface, fortunately not for the customers, because there is still a deeply baked-in assumption that coupon codes will normally be locked to single currencies and an all-currencies code is treated as an unusual exception. Who ever wants to create a single-currency coupon code on a multi-currency storefront? Why is a code conditional on a single currency the default and the only first-class type of coupon code?
Other complaints I had with BigCommerce included their relentless attempts to push real-time media like "webinars" and voice telephone instead of being willing to communicate substantively through written media like email and Web pages; their dysfunctional "community forum" where support requests go to die; their bizarre data model in which many attributes seem to be attached to the wrong database entities (which is probably the underlying cause of most of the multi-currency issues); and the fact that they won't let me ever delete "themes" from my account except versions of my customized theme. For every third-party theme I tested while setting up the store years ago, I now get an annoying notification that I can't turn off, whenever the unused theme has a new version published.
All those things were annoying and it was already my intention to switch away from BigCommerce some time in 2022. But the annoyances weren't dealbreakers; all systems have some annoyances. I'd been hoping to be able to make the switch at a leisurely pace, and shut down the BigCommerce storefront only when I had a really satisfactory alternative fully up and running. Suddenly being unable to log in with my preferred browser makes it an emergency situation with a much shorter timeline.
I had a similar problem with Stripe, my credit card payment processor, a few weeks earlier. It is clear that within the foreseeable future I will need to leave Stripe as well. However, unlike BigCommerce, when I contacted Stripe customer service about it they were able to implement a workaround in their HTML that would allow me to continue being able to log in, for the moment, without using the emergency backup browser on a separate machine that I now need for logging into BigCommerce. Although I still intend to leave them, I would like to reward Stripe for their efforts to help, by continuing to do business with them at least a few months longer.
My current plan as of this writing is to move everything to a system I am building myself, running on the same self-administered server I was already using to support customizations on the BigCommerce-hosted Web site. My priority, surprising as this may sound, is not the "shopping cart" and order-processing functions. This Web log is the most critical function of the North Coast Synthesis Web site, because most people who visit the site are coming in through Web log articles, and there are many external links pointing into the Web log. It's important to get the Web log articles onto a server I can trust not to disappear or become unmanageable, without changing their URLs. I don't actually get very many orders from retail customers through the storefront (many people buy from dealers instead) and so if I have to handle direct-to-customer orders in a less convenient way with manual intervention, it's not a huge problem for me, even if it may be a situation that lasts for a few months. Of course, if ordering directly from me is inconvenient for customers, it's kind of bad. In the long run I do really need a shopping cart system that works without surprises and without extra human intervention.
So the plan looks like this:
- First, get the Web log posted on my own server, and get the main "northcoastsynthesis.com" domain pointing at my own server. Getting this step working is an emergency crunch-mode thing. Some things on the site may not work as well as they used to when I flip the domain switch. At this point, ordering will be through a "buy now" button that points back at the old BigCommerce site.
- There may need to be a transitional period once I close my BigCommerce account, during which people who wish to place orders will have to send me email. I'll reply with Stripe invoice links allowing them to securely pay by credit card. If we go through this stage, I'll try to keep it as brief as possible.
- There are some low-priority features that existed on the BigCommerce site and won't immediately exist on the new site. I hope to bring these back eventually as my availability to work on them allows. Core features including cart and checkout are more important, but have to be done in large steps; smaller non-core features may be easy to fit in along the way.
- Eventually, I hope to get a shopping cart with good integration working on my own systems without needing to go through BigCommerce. There will probably be links to Stripe instead, to process the payments. Then customers can place orders without surprises or manual intervention, and I hope it will work better (especially with respect to multi-currency) than the BigCommerce site ever did.UPDATE AS OF MARCH 2022: We have the new shopping cart now, but not payment processing. See next entry.
- It may be that some time in 2022 I will make a further transition to the third-party e-commerce system I was already thinking of moving to before this situation occurred. They are not ready to serve customers yet, and won't be ready on the schedule I want for moving off of BigCommerce, so it appears that at least some period of self-hosting will be necessary for me first.
- It is also likely that at some point I will switch from Stripe to some other payment processor.
The move to a self-hosted e-commerce system is a lot of work and I don't like being forced to do it on short notice. I would charge a client who asked me to do this job for them thousands of dollars to do it, if I accepted the job at all; it seems reasonable that I should put a similar price on the inconvenience when I'm doing it for my own business, and that's even before we get into issues like the fact that doing this will inevitably delay important projects like the development of my next module, and it will cost me some sales as customers are put off by the more cumbersome checkout process during the transitional period. However, building my own e-commerce system does have some important advantages, many of which are going to be customer-visible, and so I'm trying to look on the bright side.
- Most of the problems I had with BigCommerce's support and implementation will vanish at a stroke as soon as I close that account. I'm really looking forward to that.
- Reduced dependency on a service run by somebody else, means I'm significantly reducing the likelihood of this kind of emergency happening again in the future. It might be called paying off a longstanding technical debt that I already knew would come due some day.
- I'm also looking forward to being able to uninstall "npm" and the other Javascript tools that I needed to maintain my BigCommerce customizations.
- The new site carries hundreds of kilobytes less client-side Javascript. That means faster loading and better accessibility. As of this writing, the only Javascript on the new storefront site, at all, is for analytics. It should be possible to use this site with Javascript turned off entirely. It may become necessary to require some client-side Javascript for payment processing, or for Web log comments, but I'm hoping to keep the Javascript requirements strictly minimal.
- YouTube still loads its client-side stuff on pages that have embedded YouTube videos, but I'm hosting thumbnails locally on the product pages, not actually embedding the videos until visitors click to watch them; that should reduce the contact between site visitors and YouTube servers.
- The new site looks better. The BigCommerce theme I was using was the best approximation I could quickly throw together - given that the 2018 transition was also done on an emergency basis - for the already imperfect Shopify theme I'd been using in 2018. Since customizing BigCommerce required working with multiple layers of whizzy "frameworks" it was never really possible for me to get it looking the way I wanted. After a few days of writing plain CSS on my new homemade site, it is a very much better approximation of my mental image of how I want my site to look, and it will be easier to maintain in the future than the Shopify or BigCommerce themes ever were.
- Because the new site runs on my own servers without depending on third parties (who often recurse to fourth and fifth parties) I can offer better security and privacy to site visitors than I could offer before the move. I'll be able to delete many of the most worrying paragraphs in my privacy policy.
See the next entry for an update on the current status of checkout.
◀ PREV A stripboard Eurorack power cable tester || Update on the new checkout NEXT ▶
MSK 013 Middle Path VCO
US$481.10 including shipping
Comments
I need to sell my products in order to keep making them, and can't really do that without a way of selling them. I do have some choice of what kind of Web shop to use, and part of the point of using BigCommerce was to save time on that. But if it's going to drop emergency "can't log in" situations on me, then it's not saving me time - and the time I'm forced to spend resolving the current emergency is best spent in a way that will prevent the same thing from happening again in the future.