Advanced Product Options

Paid pluginsize Mplanned, not built

Indicative price, not an offer: EUR 200-350/year or EUR 450 one-off

Generated from docs/plan/paid/advanced-product-options/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Simple variants (size S/M/L, color Red/Blue) aren’t enough for merchants selling customizable products. This feature provides flexible product options with visual pickers, dependencies (e.g., show color only if material is cotton), and price modifiers.

The problem

My product has 30+ combinations (material, color, size, personalization). The basic variant system doesn’t handle dependencies or visual selection, forcing customers to read text dropdowns.

What it does

• Option type: dropdown, color-picker, text-input, radio-buttons, swatch-grid
• Option modifiers: price adjustment (+$5 for premium material), weight adjustment, display rules (show/hide based on other option selection)
• Conditional options: if material=‘cotton’ then show color options; if material=‘silk’ then hide color, show sheen
• Visual selection: color picker widget, image/swatch picker (show image of each color option)
• Admin builder: drag-to-create options, set type, add choices, set modifier prices, define conditional rules
• Storefront: customer selects options, UI updates dynamically (show/hide dependent options), total price recalculates in real-time
• Order storage: selected options stored as JSON in order line item for production handoff

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Infinite customization fields (customer can enter any text) — that is advanced-product-customizer (AI design + upload)
• Dynamic inventory (option combo + stock check) — stock is per-base-product, not per-combo; no combo-level reserve
• Option templates (save as preset) — options are product-specific only

Data model

Product option schema update: options array [{id, name, type (dropdown/color/radio), required, choices [{id, label, price_modifier, display_if (JSON)}]}]. OrderLineItem schema: selected_options {option_id: choice_id, …}.

API

• GET /api/products/:id/options — fetch product options with choices (public)
• POST /api/products/:id/options/preview — input option selections, return final price/weight (public)
• POST /api/orders — create order with selected_options in line items

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Product editor, Options tab: table of options, drag-to-reorder. Create option: name, type (dropdown/color/radio), required toggle. Add choices: label, price_modifier, image (for swatch). Conditional rules: ‘Show this option if material = cotton’ (visual rule builder). Preview: test selecting options, see final price update.

The seam — why this is paid

Core owns the option model, conditional logic, and REST API. This is table-stakes CMS functionality. Paid layer owns advanced features: option templates, bulk option import, usage analytics (which option combinations are most popular).

Paid specialist feature for merchants with complex customization requirements. Not a compliance feature.

Dependencies

• Product entity with options array (must be schema migration)
• Order line item with selected_options JSON storage
• Price calculation engine (must recalculate based on option modifiers)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A product can have options: Material (dropdown: Cotton, Silk, Polyester), Color (color-picker, shown only if Material=Cotton)
• Customer selects Material=Cotton; Color picker appears, Price is base €50
• Customer selects Color=Red; if Color adds €5 modifier, Price updates to €55 in real-time
• Customer selects Material=Silk; Color picker disappears (conditional rule: hidden)
• Order line item stores selected_options: {Material: ‘Cotton’, Color: ‘Red’}
• At checkout, final price includes all modifiers

Risks

Conditional logic can become complex; UI can become confusing if too many dependencies. Price calculation must include all modifiers in correct order (option A affects price, option B depends on A); evaluation order matters. Missing options on save can break orders (if option is deleted after customer selected it, order is invalid); document as limitation or implement soft-delete for options.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.