Products: create a single product via the admin UI #25

New Issue

2026-06-11T16:09:52Z

ben.stull commented

2026-06-11 16:09:52 +00:00

Summary

Single-product authoring: a merchant can create one new product by entering its
data directly in the admin and saving it — without constructing a bulk import
file.

Problem / pain

Adding products to a storefront is bulk-or-nothing today: the Products MVP
deliberately ships CSV import/export as the only way to mutate the catalog
(#13). That fits a migrating merchant moving hundreds of rows, but it is the
wrong shape for the most common everyday action — "I just got one new product
in, let me add it." To add a single item a merchant has to construct or edit a
whole CSV file, get the columns right, and run a bulk import for one row, then
re-export to keep their file current — a heavyweight, error-prone ritual for a
one-line change. It bites hardest at first run: a merchant evaluating the
platform wants to add their first product and see it appear, and being forced
into spreadsheet authoring on day one is a steep, off-putting first step that
makes a fresh storefront feel harder to populate than it is.

Who feels it

persona	role	what they need
Merchant	storefront owner adding a one-off product	add a single new product quickly, without touching a spreadsheet, when one item changes
New merchant	prospective customer evaluating the platform	add their first product directly and see it land in the catalog, to confirm the platform works before committing a bulk migration

Desired outcome / value

The everyday "add one product" action no longer requires authoring a bulk file:
a merchant can put a single product into their catalog directly in the admin.
The barrier to a first populated catalog drops, first-run evaluation succeeds in
one step, and bulk import is freed to be what it is best at — migration and
mass updates — rather than the only door in.

Acceptance — "done right"

A merchant can create a new product by entering its data directly in the
admin and saving it.
The created product then appears in the storefront's catalog (the list and
its read-only detail) and is indistinguishable from a product that arrived by
bulk import — including being carried out by export.
Required product data is validated on save, and a rejected entry is reported
back with feedback the merchant can act on.

Scope / non-goals

In: creating a single new product directly in the admin.

Out:

Bulk add/update of products — that is the CSV mechanism (#13).
Editing or deleting existing products via the UI — the product detail view
stays read-only for now; in-UI edit/delete is a natural adjacent ask, but
it is not this Feature.
Shopper-facing storefront authoring — this is the merchant-side admin.

Assumptions · constraints · dependencies

Parent: #12 (Products MVP epic). Changes the epic's boundary: #12 today
states bulk CSV is the only mutation mechanism — this Feature makes
single-product UI authoring a second mechanism, so #12's non-goals and
acceptance are amended alongside filing this.
Sibling: #13 (CSV import/export) — both write the same product, so the two
paths must agree on the canonical product field set.
Relates to: #14 (list + read-only detail) — the created product surfaces
there.
As a type/feature, requires a Solution Design before an implementation plan
(handbook §4.3 gate).

Source / signal

Operator ask, capture session ecomm-0031 (2026-06-11) — adding a per-product
authoring path to the Products MVP epic (#12).

Priority (WSJF)

Value 6 · Time-criticality 4 · Opportunity-enablement 4 ÷ Size 3 ≈ 4.7 —
high-value for first-run onboarding and everyday one-off adds, and small
relative to the bulk path → priority/P1.

Decomposition

Deferred — slicing belongs to the Feature's Solution Design (handbook §4.3).

Solution notes (optional — NOT a design, non-binding)

The single-product authoring form and the CSV import (#13) write the same
product; they should derive from one canonical product field definition so
the two paths cannot drift.
A future in-UI edit affordance would likely reuse this Feature's form and
validation — worth keeping the authoring surface factored so edit can be
added without a rewrite. (Edit/delete remain out of scope here.)

## Summary Single-product authoring: a merchant can create one new product by entering its data directly in the admin and saving it — without constructing a bulk import file. ## Problem / pain Adding products to a storefront is bulk-or-nothing today: the Products MVP deliberately ships CSV import/export as the only way to mutate the catalog (#13). That fits a migrating merchant moving hundreds of rows, but it is the wrong shape for the most common everyday action — "I just got one new product in, let me add it." To add a single item a merchant has to construct or edit a whole CSV file, get the columns right, and run a bulk import for one row, then re-export to keep their file current — a heavyweight, error-prone ritual for a one-line change. It bites hardest at first run: a merchant evaluating the platform wants to add their first product and see it appear, and being forced into spreadsheet authoring on day one is a steep, off-putting first step that makes a fresh storefront feel harder to populate than it is. ## Who feels it | persona | role | what they need | | --- | --- | --- | | Merchant | storefront owner adding a one-off product | add a single new product quickly, without touching a spreadsheet, when one item changes | | New merchant | prospective customer evaluating the platform | add their first product directly and see it land in the catalog, to confirm the platform works before committing a bulk migration | ## Desired outcome / value The everyday "add one product" action no longer requires authoring a bulk file: a merchant can put a single product into their catalog directly in the admin. The barrier to a first populated catalog drops, first-run evaluation succeeds in one step, and bulk import is freed to be what it is best at — migration and mass updates — rather than the only door in. ## Acceptance — "done right" - A merchant can create a new product by entering its data directly in the admin and saving it. - The created product then appears in the storefront's catalog (the list and its read-only detail) and is indistinguishable from a product that arrived by bulk import — including being carried out by export. - Required product data is validated on save, and a rejected entry is reported back with feedback the merchant can act on. ## Scope / non-goals **In:** creating a single new product directly in the admin. **Out:** - Bulk add/update of products — that is the CSV mechanism (#13). - Editing or deleting existing products via the UI — the product detail view stays read-only for now; in-UI edit/delete is a natural adjacent ask, but it is not this Feature. - Shopper-facing storefront authoring — this is the merchant-side admin. ## Assumptions · constraints · dependencies - Parent: #12 (Products MVP epic). **Changes the epic's boundary:** #12 today states bulk CSV is the *only* mutation mechanism — this Feature makes single-product UI authoring a second mechanism, so #12's non-goals and acceptance are amended alongside filing this. - Sibling: #13 (CSV import/export) — both write the same product, so the two paths must agree on the canonical product field set. - Relates to: #14 (list + read-only detail) — the created product surfaces there. - As a `type/feature`, requires a Solution Design before an implementation plan (handbook §4.3 gate). ## Source / signal Operator ask, capture session `ecomm-0031` (2026-06-11) — adding a per-product authoring path to the Products MVP epic (#12). ## Priority (WSJF) Value 6 · Time-criticality 4 · Opportunity-enablement 4 ÷ Size 3 ≈ **4.7** — high-value for first-run onboarding and everyday one-off adds, and small relative to the bulk path → `priority/P1`. ## Decomposition Deferred — slicing belongs to the Feature's Solution Design (handbook §4.3). ## Solution notes (optional — NOT a design, non-binding) - The single-product authoring form and the CSV import (#13) write the same product; they should derive from one canonical product field definition so the two paths cannot drift. - A future in-UI edit affordance would likely reuse this Feature's form and validation — worth keeping the authoring surface factored so edit can be added without a rewrite. (Edit/delete remain out of scope here.)

ben.stull added the type/feature priority/P1 labels 2026-06-11 16:09:52 +00:00

ben.stull referenced this issue

2026-06-11 16:10:59 +00:00

Products: list (sort/search/column selection) + read-only detail view #14

ben.stull referenced this issue

2026-06-11 16:10:59 +00:00

Products MVP — product catalog: list + read-only detail, bulk CSV import/export, kits #12

ben.stull commented

2026-06-12 16:16:27 +00:00

Closing as part of the pivot from a generic multi-tenant Shopify-alternative storefront to the commitment-commerce + cross-maker verified referral network direction (see ecomm-content/rfcs/network_strategy.md; session 0036).

Single-product create via admin UI is storefront catalog admin — Medusa's admin provides this. Superseded.

Nothing is lost — code stays in git history and the issue can be reopened if it resurfaces under the network architecture.

Closing as part of the pivot from a generic multi-tenant Shopify-alternative storefront to the commitment-commerce + cross-maker verified referral **network** direction (see `ecomm-content/rfcs/network_strategy.md`; session 0036). Single-product create via admin UI is storefront catalog admin — Medusa's admin provides this. Superseded. Nothing is lost — code stays in git history and the issue can be reopened if it resurfaces under the network architecture.

ben.stull closed this issue

2026-06-12 16:16:27 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiggleverse/wiggleverse-ecomm#25