Industry
Drupal Commerce stores and the systems behind them: catalogue, payments, tax, and stock and prices from your own records.
An engineer reads it and replies within one business day.
Who we build this for
Case studies
Apex Embroidery Designs, a family business in North Carolina, sells machine embroidery designs, embroidery fonts and cuttable SVG files at apexembdesigns.com. We designed the store and rebuilt it on Drupal, moving it from Drupal 7 to Drupal 9 with 20 million items migrated from the old store, and we maintain it. Every product is a digital file offered in the file formats of the embroidery machines its customers use and delivered as an instant download, and custom digitizing orders come in through the same site.
It is a catalogue and storefront project rather than a marketplace, and the case study describes what was delivered.
What shapes the work
Storefronts are easy to launch and hard to keep honest. The failures cluster in the same places, and none of them are visible on launch day.
Variants, bundles, configurable products, units of sale that differ by customer type. A catalogue modelled too simply at the start is re-modelled later with live orders in it.
When stock lives in a warehouse system, a marketplace and a storefront at once, the question is not whether they disagree but how quickly the disagreement is caught and who the customer blames.
The moment a store becomes a marketplace it needs vendor onboarding, per-vendor pricing and stock, commission, payouts and dispute handling. That is a different system, not a setting.
Cards in one market, bank transfer in another, local wallets elsewhere, and B2B customers who expect an invoice and terms rather than a checkout.
Account-specific price lists, approval chains, purchase orders, quotes and reorder from history are the requirement, not extras.
How we build it
The storefront is the visible part of a commerce build and rarely the expensive part. The work usually goes into the systems behind it, and on Drupal it is our Drupal Commerce development work.
Product options, size sets and file formats modelled as data, and a catalogue customers can browse by subject, style and technique rather than one long list.
Integration with the ERP, accounting or warehouse system that holds the real stock and the real prices.
Payment methods and tax rules for the markets you actually sell in.
Account pricing, approval workflow, purchase orders, and reorder from order history.
A Drupal 7 store rebuilt on current Drupal with its catalogue, customers and orders carried across: our Drupal migration work.
Tax rounding, partial refunds, cancelled orders that already shipped one line, stock reserved by an abandoned basket, a payment that succeeded at the gateway and failed to record. None of it appears in a specification and all of it appears in the first month of trading, so we design for it from the start.
A store with your branding and integrations on a well-understood commerce model sits at the Small to Medium sizes on our pricing page, rising to Large as it is extended, and further still where the commerce model itself is unusual. We build a working demo on your own catalogue before you commit, because catalogue structure is exactly what a generic demo hides.
The source code is yours (no licence on your own platform), and development work carries a warranty of one year by default and up to three (the terms). Ongoing operation, patching and upgrades run under support and maintenance.
Not the number of products. In roughly this order:
We work through each of these in a requirements session, then build a prototype against a slice of your real catalogue. The architecture is designed from what that exposes, and the price is fixed after it, not before. Questions that come up before that are answered on our FAQ page.
We build a working prototype first, so you decide against something real.
