Daniel Immke

I recently wrapped up a very large WooCommerce build that I am planning on writing a case study for next month. In the meantime, I thought I would share some of the lessons I learned and pitfalls I hit. This is obviously not a comprehensive list, but these are the things that became big issues for me and I think it would be useful for other freelancers. These items are both technical and business related.

1. There is a plugin for that—but be careful

Just like with WordPress, there are tons of plugins for WooCommerce. If you are encountering a problem, it’s likely that someone else has solved it and is trying to sell it to you for $70. In fact, because plugin authors know that an e-commerce site is more likely to pay for a plugin they create them for small functionality. I saw plugins that were maybe 30 lines of code functionality with an admin panel slapped on.

There’s nothing wrong with that, but if you are doing a custom build these plugins add a lot of technical debt. They are highly variable in quality, and after buying a few and installing them only to find that they didn’t do quite what I needed or were a security risk or they just plain sucked I decided to just build my own solutions whenever possible.

Obviously for larger scale functionality it is worth it to go with a reputable, popular plugin but I saved myself a lot of grief and my client a fair amount of additional cash by keeping extraneous plugins to the minimum.

2. Know your vendors

Know exactly what third party services your client is planning on using, especially their payment processor and how good their WooCommerce integrations are before you submit a proposal. My client had a specific company in mind to handle their payments that they wanted to use because that company also did their bookkeeping. I said “Sure, we can use them- as long they have a WooCommerce plugin.” They did, so I wrapped that into my quote.

After getting into the project, it turned out that their online payment stuff was a complete mess. The payment processor had a legacy system and a new system and poor documentation for both. Their plugin was developed by a third party so we had to talk to two different support teams when trying to figure out where the errors were coming from. The issues we had with this delayed the project by months.

Definitely do your research, and if your client isn’t married to a specific option it’s generally best to go with the most popular options like Stripe or Authorize.net.

3. A lot of things changed earlier this year

If you have a snippet from StackOverflow that isn’t working, it might be because WooCommerce made some big changes when they moved into 3.x earlier this year. This includes stuff like accessing stored information about a product etc…

More than once I ran into a situation where a code suggestion or explanation from a third party site didn’t work and I had to dig into the official documentation to come up with my own solution.

4. Stick to the established UI patterns

While a very powerful part of WooCommerce is how extensible and easy to change it is, there are certain things that WooCommerce is very opinionated on. These things are hard to change without extensive additional development time. As an example, my clients wanted to split the checkout process into several parts. This is actually fairly difficult to do using the normal tools that WooCommerce provides. Even the plugin I found that did it used a pretty hacky workaround that involved hiding sections with CSS.

If your client wants to do things with the purchase flow that are outside of the WooCommerce default, research them and work that into your quote.

That’s it!

Those are the big ones. I hope I helped or at least gave you a heads up. I’m planning on doing a lot more WooCommerce work in the future, so I might keep writing on this topic. Thanks for reading.