DEV Community

Daniel Ioni
Daniel Ioni

Posted on

Building MyZubster Marketplace Demo v2: From Static Examples to an Interactive Product Experience

Building MyZubster Marketplace Demo v2: From Static Examples to an Interactive Product Experience

We’ve been evolving MyZubster Marketplace from a basic listing experience into something that people can actually explore, understand and test before interacting with the real marketplace.

The latest work focused on one specific question:

How do you demonstrate a marketplace without creating fake orders, fake payments or misleading activity?

That led to Marketplace Demo v2.

First step: complete category coverage

The Marketplace supports 12 categories, but the demo layer initially covered only part of them.

We recently completed the missing categories so that the demo now represents the full Marketplace taxonomy:

Seeds
Plants
Produce
Clothing
Accessories
Event equipment
Tools
Services
Volunteering
Pet adoption
Pet lost & found
Pet services

We also added regression coverage so that a new category cannot be introduced later without demo representation.

That gave us 12/12 category coverage.

But simply having 12 cards still wasn’t enough.

The problem with static demos

A static card can show an idea, but it doesn’t really explain how a marketplace behaves.

A visitor should be able to understand things like:

what a listing contains,
how categories differ,
how discovery works,
what happens after clicking “request,”
which actions are real and which are simulated.

So we moved the demos into the main Marketplace experience instead of maintaining a completely separate showcase page.

Marketplace Demo v2

The new demo experience now includes interactive listing details.

Users can open a demo and see richer information such as:

description,
location,
availability,
category,
payment mode,
contextual fields,
simulated demand.

The demos still remain clearly marked as DEMO.

They are not real sellers and do not accept real orders or payments.

Filtering the demos like real listings

The demo layer can now be explored using practical filters.

Users can filter by:

Category

Location

Text search

Payment type

Including examples such as:

FREE

BARTER

EUR

MYZ

This is important because the goal is no longer just to display examples.

The goal is to let someone experience how Marketplace discovery will actually feel.

Simulating the request flow safely

One of the most useful additions is a simulated request flow.

A user can open a demo listing, start a request and move through a confirmation experience.

But the system deliberately does not call the real order APIs.

It does not:

create an order,
charge a payment method,
send a real message,
store personal request data.

That gives us a way to demonstrate the product journey without polluting production data.

Not every category should behave like a product

Another important lesson came from the community categories.

A pet adoption listing should not behave exactly like selling a jacket.

A lost pet alert should not behave like renting audio equipment.

A volunteering opportunity should not be modeled as a normal paid product.

So the new demo model introduces specialized contextual fields for categories such as:

Volunteering

Role, commitment and community purpose.

Pet adoption

Animal profile, adoption context and responsible placement information.

Lost & found pets

Approximate area, status and safe contact context.

Pet services

Type of care and availability.

The category system is becoming more than a label.

It can influence the experience itself.

One demo system instead of two

Previously, MyZubster also had a separate /marketplace-demos page containing static examples for things like:

coding,
cybersecurity,
animals,
music,
volunteering,
environmental pilots.

It was useful as inspiration, but it had become a second demo system.

That creates duplication and eventually drift.

So we are consolidating the experience.

The old demo route now points users toward the main Marketplace demo experience instead.

The goal is simple:

One Marketplace, one demo model, one source of truth.

Payments remain separate from demos

This work is happening alongside improvements to MyZubster’s monetization architecture.

We recently clarified the distinction between different paid products such as:

Marketplace Seller

and

Zorgax Pro

Even if two products happen to have the same monthly price, the payment system must still understand what was actually purchased.

The Marketplace demos follow the same philosophy.

Demo interactions should never create financial state.

Real Seller subscriptions remain real Stripe subscriptions.

Demo requests remain simulated.

That separation is intentional.

What we have now

At this stage, MyZubster Marketplace has:

✅ 12/12 category demo coverage
✅ interactive demo details
✅ category and location filters
✅ text search
✅ payment-mode filtering
✅ safe simulated request flow
✅ specialized pet and volunteering fields
✅ unified demo experience
✅ regression tests for category coverage
✅ no fake orders
✅ no fake payments

The interesting part of building a marketplace isn’t just creating a “Buy” or “Request” button.

It’s defining where simulation ends and real economic activity begins.

That boundary has to be obvious in both the UI and the architecture.

We’re continuing to build MyZubster with that principle in mind:

real transactions stay real, demos stay demos, and the product should still be understandable before anyone spends money.

MyZubster #WebDevelopment #JavaScript #React #NodeJS #Marketplace #Stripe #BuildInPublic #IndieDev #ProductDevelopment

Top comments (0)