Commerce

WooCommerce and custom commerce development

Commerce on WordPress is two different projects depending on what you are selling. A catalogue of physical products with shipping, tax and inventory is what WooCommerce exists for. A membership, a course, a subscription or a payment attached to a service often is not, and building it on a commerce platform means inheriting a great deal of machinery to switch most of it off.

  • The platform decision made first, on what you are actually selling
  • WooCommerce built properly where it fits: theming, templates, extensions
  • Custom commerce where a full store is the wrong shape
  • Payments, subscriptions and document generation built directly where that is simpler
Discuss your project
First question

Is WooCommerce the right tool here?

WooCommerce is the right answer for a large share of commerce on WordPress, and when it is, using anything else is expensive stubbornness. It brings products, variations, cart, checkout, tax, shipping, orders, refunds, reporting and a very large extension ecosystem, all of which someone would otherwise have to build and maintain.

It is the wrong answer often enough to be worth asking. A membership with two tiers and a recurring charge, a course with enrolment and progress, a deposit taken against a booking, or a single product sold with a generated invoice. These can all be done in WooCommerce, and they usually arrive as a store with most of its features disabled, a checkout customized past recognition, and four extensions whose renewal costs and update cycles now belong to the client.

So we start with the decision rather than the build, and we are prepared to talk an organization out of the platform they came in asking for. That is the most valuable thing on this page.

WooCommerce fits

Multiple products with variations, real inventory, shipping and tax rules, order management workflows, and a team that needs a familiar store back end. The ecosystem is the asset, and the maintenance overhead is worth paying.

Custom fits

One product or a handful. A subscription, a membership or a course. A payment attached to something that is not a product. A checkout that has to behave differently from a store’s. Here a direct payment integration is less code, fewer dependencies and less to maintain.
WooCommerce work

Building on WooCommerce properly

Theming and templates

Store, product, cart and checkout templates built into the site’s design system rather than left as a visually foreign section wearing a stylesheet.

Custom functionality

Extensions written where the ecosystem does not have the behaviour, rather than approximating it with three plugins and a filter chain.

Payments and integration

Gateways configured correctly, and orders connected to the systems the organization actually runs: accounting, CRM, fulfilment, member records.

Performance

Stores are query-heavy and get slower with catalogue size. Query, caching and template work rather than a caching plugin applied at the end.

Accessibility and checkout

Checkout is the least forgiving thing on a site to get wrong for keyboard and screen reader users, and the most commonly broken by customization.

Dependency discipline

Every extension is a renewal, an update cycle and a security surface. We keep the count deliberately low and document what each one is for.

Start a project

Selling something on WordPress?

Tell us what you are selling and how the purchase has to work. The platform decision takes one conversation and saves a great deal more than it costs.

Tell us about your project
Evidence

Custom commerce, in practice

The clearest commerce project in our portfolio deliberately did not use WooCommerce. iAmEvolving® is a custom e-commerce, newsletter and course platform built on WordPress with Stripe PaymentIntents and Subscriptions handling payment in two currencies, token-based delivery for digital downloads, generated PDF invoices, a newsletter and automation engine running off cron, and thirty-five custom blocks for the editorial side. The requirement was a specific purchase and enrolment flow rather than a store, and building it directly produced less code and fewer dependencies than configuring a commerce platform to behave that way.

We include it here as evidence of judgement rather than as a WooCommerce case study, because it is not one. If your project needs a conventional store, WooCommerce is very likely the right recommendation and we will make it.

FAQ

Frequently asked questions

  • Should we use WooCommerce or build something custom?

    Count your products and look at your checkout. A catalogue with variations, real inventory, shipping and tax rules, and a team that needs an order back end is what WooCommerce exists for, and rebuilding that is expensive stubbornness. One product, a membership, a course, a subscription, or a payment attached to a service is usually a store with most of its features switched off and four extensions on the renewal list. We make that call in one conversation, before any build.

  • Can you take over an existing WooCommerce store?

    Yes, after an assessment. Inherited stores are usually carrying extensions nobody can now account for, a checkout customized past the point of safe updating, or both. The assessment tells you which of those is true and what it costs to get current. See maintenance and support for how the ongoing side runs.

  • How many extensions will we end up with?

    As few as we can manage, and every one of them documented with what it is for. Each extension is a licence renewal, an update cycle and a security surface, and the compounding cost of a large extension list is the single most common reason an older WooCommerce site cannot be updated safely.

  • Do you handle subscriptions and memberships?

    Yes, and this is exactly where the platform question matters most. Subscriptions inside WooCommerce mean the store plus an extension plus its renewal. Built directly against Stripe Subscriptions it is often less code and fewer moving parts. iAmEvolving® is the second of those, with recurring billing and course enrolment in one custom system.

  • Will a large catalogue make the site slow?

    WooCommerce is query-heavy and it does get slower as a catalogue grows, but that is a solvable engineering problem rather than an inevitability. It is solved with query and template work and a deliberate caching strategy, decided at architecture. It is not solved by installing a caching plugin at the end and hoping.

  • Is the checkout accessible?

    It is the part of a store least forgiving to get wrong and the part most often broken by customization. Keyboard operation, focus management, error handling and clear labelling in checkout are treated as build requirements rather than as a later audit. See accessibility.