Rethinking Product Variants: From One Product to Many

All I wanted to do was support something simple:

A seller should be able to list banana bread…
with and without choco chips… at different prices.

That’s it.

But somehow, this turned into:

• product vs variant debates

• option vs attribute confusion

• structured vs flexible nightmares

Classic overengineering spiral.

The Bakery Thought Experiment

Then I imagined something very real.

You walk into a bakery.

Behind the glass, you see:

• Banana Bread = ₹199

• Banana Bread with Choco Chips = ₹249

They’re sitting right next to each other.
Different trays. Different prices. Same base item.

And your brain doesn’t go:

“Ah yes, this is one product with two variants.”

No.

Your brain goes:

“There are two things I can buy.”

That’s when it clicked

The problem wasn’t technical.

It was how I was thinking about the model.

I was forcing everything into:

“One product → many variants”

But in reality, what I had was:

• One Offering (Banana Bread)

• Multiple purchasable Products

The Mental Model Shift

Instead of this:

Product
  └── Variants (500gm, 1000gm, choco chips, etc.)

I moved to this:

Offering (Banana Bread)
  ├── Product → Classic → ₹199
  └── Product → With Choco Chips → ₹249

Each variant is not a “child object”.

It’s a real product.

Something you can:

• price independently

• track inventory for

• show directly to users

Where It Gets Messy

Then came the real problem.

How do you handle:

• size (500gm, 1000gm)

• dimensions (20x30 cake)

• weird stuff like “extra toppings” or "added cheese"

I tried two extremes:

1. Everything structured

quantity: 500
unit: gm
dimensions: {...}

Clean. Queryable. Backend-friendly.

But…

Where does “extra toppings” go?

2. Everything flexible (options)

Flavor: Butterscotch
Size: 500gm

Flexible. Easy to extend.

But…

Now you can’t filter, sort, or reason about anything properly.

The Balance That Actually Works

So I stopped trying to be perfect.

And split things into 3 layers:

1. Structured fields (for the system)

• quantity

• unit

• dimensions

• weight

Used for:

• filtering

• logistics

• analytics

2. Label (for humans)

This is the most important field.

What the customer actually sees:

• “500gm”

• “With Choco Chips”

• “Large”

This becomes the single source of truth for display

3. Optional custom options (for edge cases)

Only when needed:

• Flavor → Butterscotch

• Topping → Extra Nuts

Not forced. Not everywhere. Just when it makes sense.

The UI Changed Everything

Instead of complex variant builders…

I made it stupid simple:

*[ Label ]        → "With Choco Chips"
*[ Price ]        → ₹249

[ Quantity ]     → 500 gm
[ Dimensions ]   → L x W x H

[ Add custom option ]
  Flavor → Butterscotch
                                            [+ Add Variant]

And that’s it.

The Unexpected Truth

Most sellers don’t care about your schema.

They will just type:

• “Banana Bread”

• “₹199”

And move on.

They don’t wake up thinking:

“Should I define an option group with normalized values?”

They just want to list and sell.

Real moments where they pause

• When price changes
  → “Wait, choco chips costs more”

• When the choice is obvious
  → “Small vs Large”
  → “500gm vs 1kg”

• When customers usually ask
  → “Do you have eggless?”
  → “Do you add nuts?”

• When it affects decision-making
  → “Full hands mehendi vs half hands”
  → “Basic vs premium package”

In those moments, something shifts.

They pause and think:

“Okay… I should probably show this as an option.”

Not because your system told them to;
but because their customer expects it.

And the UI should meet them right there

No complex setup. No forced structure.

Just a simple:

[ + Add Variant ]

They click it… and add:

• a new label → “With Choco Chips”

• a new price → ₹249

• (optionally) more details if they care

No “define option groups”
No “configure attributes”
No mental overhead

Just:

“Here’s another version of the same thing I’m selling.”

The Real Lesson

Variants shouldn’t feel like configuration.
They should feel like adding another item to the shelf!

Final Takeaway

Stop trying to design the “perfect” variant system.

Instead:

• Model real-world behavior

• Keep data readable

• Allow flexibility without forcing it

That bakery shelf taught me more than hours of schema design ever did.

Panchhee isn't trying to be the most powerful marketplace.

It's trying to be the simplest one.

There are already countless marketplaces for complex setups; Panchhee is for people who just want to list and sell.

Happy Building!