Replace WooCommerce Product Add-Ons with DashCommerce

What Woo Product Add-Ons actually does

WooCommerce ships with two product types that matter here: simple products and variable products. Variable products handle structured options — size small/medium/large, color red/blue/green — where each combination is a real SKU with its own price and stock count. That’s the easy case.

The hard case is everything else. A jeweler selling engraved rings needs to collect the engraving text. A print shop selling custom mugs needs the customer to upload artwork. A gift site needs a checkbox for “add gift wrap (+$5)” and a text area for a gift message. A cake shop needs a dropdown for flavor with a price delta and a radio group for tier height.

None of that fits into variants cleanly. Woo Product Add-Ons is Automattic’s official $79/year extension that gives merchants an admin UI for assembling those fields per product. You drag and drop text fields, checkboxes, dropdowns, radio buttons, file upload inputs, and date pickers onto a product; you set required/optional; you set price deltas per option; you set conditional visibility. The storefront renders the resulting form; the customer fills it in; the data is stored as WooCommerce product meta and flows through to the order.

It’s a mature product. It’s well documented. It has years of iteration behind it. It solves a real problem that WooCommerce core does not.

The DashCommerce equivalent, and where it falls short

DashCommerce approaches product options through two mechanisms, and the gap between them matters for this comparison.

The first mechanism is the variable product type — one of six product types DashCommerce ships. It handles structured variant grids cleanly: attributes define the axes (size, color, material), variants are generated for each combination, each variant carries its own SKU, price, inventory, and image. For any product where options are a finite grid and each combination is a real SKU, variable is the right answer and it is genuinely clean.

The second mechanism is schema extension. Because EmDash collections are typed, you can extend the products collection schema with additional fields — engraving_text, monogram_letters, gift_message — that become part of the product type. This is real, type-safe schema work. It is not, however, what Woo Product Add-Ons delivers. Two key differences:

It requires editing the schema, not clicking in an admin. Adding a field means editing seed.json or the collection definition and redeploying. A merchant cannot add a new field to one specific product without a developer involved.

It does not ship a configurator UI. DashCommerce tells you what fields a product has; it does not render a drag-and-drop form builder so merchants can assemble per-product option layouts. That UI layer is missing from v0.1.3.

For a heavily customized catalog — hundreds of SKUs each with their own bespoke set of fields — this gap is real and we’re not going to dress it up.

When structured variants are enough

The good news: a large percentage of what merchants reach for Woo Product Add-Ons for is actually better modeled as structured variants, and DashCommerce handles those cleanly.

If you sell t-shirts in four sizes and six colors at three different prices (S/M are $25, L/XL are $28, 2XL is $32), that’s a variable product in DashCommerce. You define the attributes, the admin generates the variant grid, you set prices per variant. No configurator needed.

If you sell a coffee subscription with three grind options (whole bean, drip, espresso) and two bag sizes (12oz, 2lb), that’s a variable subscription product in DashCommerce. Same pattern.

If you sell SaaS plans with three tiers and two billing intervals (monthly/annual), that’s six variants on a subscription product type.

For this shape of catalog — options are finite, combinations are real SKUs, prices attach to variants — DashCommerce is fine. No storefront configurator code is required.

When you need custom-field product pages

This is where v0.1.3 is not the right tool, and we’re being direct about it.

If your product page needs to collect a free-form text input from the customer (“what should we engrave on the ring?”), a file upload (“upload your logo for the mug”), conditional options (“if ‘premium’ is selected, show the ‘signature style’ dropdown”), or per-product checkbox upsells that a non-developer needs to be able to add without editing code — DashCommerce does not ship this out of the box.

What DashCommerce ships in this space:

• Typed product schemas you can extend with custom fields (developer work, not merchant work).
• Cart-item metadata support, so whatever inputs you collect can flow through to the order.
• Variable products for structured options.

What DashCommerce does not ship:

• An admin-facing configurator builder.
• A conditional-logic engine for option visibility.
• A file-upload input type.
• Per-option pricing rules outside the variant system.

This is the category where Woo Product Add-Ons, a focused $79/year plugin that’s been iterated on for years, does a specific job better than a general-purpose open-source commerce plugin at v0.1.3.

Building a configurator on the storefront

For teams committed to DashCommerce who need some custom-field behavior today, here’s the realistic sketch.

On the product detail page, render a form with whatever inputs the product needs — text, textarea, select, file upload. The inputs live in your Astro/React component code, not in admin config. Validate required fields client-side before allowing add-to-cart.

When the customer adds to cart, attach the collected input as cart-item metadata. DashCommerce’s cart supports arbitrary per-line-item metadata, so your engraving text or uploaded file URL rides along with the cart item through checkout and into the order record.

For file uploads: handle the upload yourself. R2, S3, or Cloudflare Images are the usual targets. Store the resulting URL in cart-item metadata; render it back to the admin order view via a small custom order detail component.

For conditional visibility: plain JS/TS in your component. When the “premium” option is selected, reveal the “signature style” dropdown. There is no rules engine to configure — there is just code.

This approach works. It is also meaningfully more effort than installing a $79 plugin on WooCommerce that does the same thing. If the effort is worth it because you’re already committed to the DashCommerce stack for other reasons (no platform fees, typed end-to-end, edge-hosted, MIT-licensed), good. If the only reason you’re considering the migration is to replace Woo Product Add-Ons specifically, this is the wrong migration to prioritize.

The honest recommendation

If Woo Product Add-Ons is core to your business today — if your product catalog is dominated by configurable SKUs with per-order custom fields that merchants need to assemble without developer help — DashCommerce is not the replacement for this specific plugin yet. Stay on Woo. Pay the $79 a year. It’s a fair price for a mature, purpose-built tool.

If your catalog is mostly structured variants with only occasional custom-field needs, DashCommerce can cover the structured side cleanly and you can build the occasional custom-field product page by hand on the storefront.

If you are migrating off WordPress for reasons that have nothing to do with Product Add-Ons — platform-fee avoidance, stack unification, typed schemas, edge deployment — then this is one of the gaps you will cross during the migration. Budget storefront engineering time for the custom-field products. Don’t pretend it’s free.

We will revisit this page when DashCommerce ships a configurator primitive. Today, it has not, and the right answer is to say so.